From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0002.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0001.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0003.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0002.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0004.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0004.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0005.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0005.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0006.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0006.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0001.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0007.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0007.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0002.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0008.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0008.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0004.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0009.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0009.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0005.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0010.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0010.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0006.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0011.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0011.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0007.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0012.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0012.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0008.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0013.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0013.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0009.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0014.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0014.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0010.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0015.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0015.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0011.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0016.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0016.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0012.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0017.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0017.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0013.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0001.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0018.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0018.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0014.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0002.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0019.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0019.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0015.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0003.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment.html From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0020.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0020.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0016.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0004.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0001.html From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0021.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0021.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0017.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0005.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0002.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0022.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0022.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0018.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0006.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0003.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0023.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0023.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0019.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0007.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0005.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0024.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0024.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0020.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0008.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0006.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0001.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0025.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0025.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0021.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0009.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0007.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0002.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0001.html From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0026.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0026.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0022.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0010.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0008.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0004.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0002.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0027.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0027.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0023.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0011.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0009.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0005.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0003.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0028.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0028.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0024.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0012.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0010.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0006.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0004.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0029.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0029.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0025.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0013.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0011.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0007.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0005.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0030.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0030.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0026.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0014.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0012.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0008.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0006.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0031.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0031.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0027.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0015.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0013.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0009.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0007.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0032.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0032.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0028.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0016.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0014.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0010.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0008.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0033.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0033.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0029.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0017.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0015.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0011.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0009.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0034.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0034.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0030.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0018.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0016.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0012.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0010.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0035.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0035.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0031.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0019.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0017.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0013.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0011.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0036.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0036.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0032.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0020.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0018.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0014.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0012.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0037.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0037.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0033.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0021.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0019.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0015.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0013.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0038.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0038.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0034.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0022.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0020.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0016.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0014.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0039.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0039.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0035.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0023.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0021.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0017.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0015.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0040.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0040.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0036.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0024.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0022.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0018.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0016.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0041.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0041.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0037.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0025.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0023.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0019.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0017.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0042.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0042.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0038.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0026.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0024.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0020.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0018.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0043.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0043.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0039.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0027.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0025.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0021.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0019.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0044.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0044.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0040.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0028.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0026.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0022.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0020.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0045.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0045.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0041.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0029.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0027.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0023.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0021.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0046.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0046.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0042.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0030.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0028.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0024.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0022.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0047.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0047.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0043.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0031.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0029.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0025.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0023.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0048.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0048.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0044.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0032.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0030.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0026.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0024.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0049.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0049.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0045.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0033.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0031.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0027.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0025.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0050.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0050.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0046.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0034.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0032.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From tjarvi at qbang.org Fri May 23 19:34:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:34:57 -0600 (MDT) Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: On Fri, 23 May 2008, TRAN, Loi X. wrote: > We're attempting to use a Silicon Labs part number CP2103 which looks > like a RS232 port. The part itself is a USB port. It's currently run > at 460.8Kbaud. Using the class below, we sent out an array of bytes of > length defined by what's passed in. We have a problem in that the data > being sent out of the USB port has wide gaps in time (~20 - 30 > milliseconds) between each byte sent. How can we force the bytes to be > burst out with minimal delay (<5 ms) between each byte? Has anyone > experienced this problem? > > import java.io.IOException; > import java.io.OutputStream; > > public class SerialWriter implements Runnable > { > private OutputStream out; > private int count; > private byte[] c; > > public SerialWriter ( OutputStream out, byte[] c ) > { > this.out = out; > this.c = c; > } > > public void run () > { > try > { > for (count = 0; count < c.length; count++) > out.write(c[count]); > } > catch (IOException e) > { > e.printStackTrace(); > } > } > } > The operating system can be busy for 8-10 ms between each write above. I'd recommend sending the array of bytes to write and let the lower level code handle it. The more that is done in the kernel, the better. Beyond that, you may need to modify the native code to accept larger arrays and handle the writes without jumping between layers in the driver. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri May 23 19:38:30 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 23 May 2008 19:38:30 -0600 (MDT) Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: On Thu, 22 May 2008, Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > I've not seen this. You may try and catch the exception in the Java code. Perhaps if it is loaded, there is no need to load it again. /usr/src/rxtx/rxtx-2.1-7/src/CommPortIdentifier.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXCommDriver.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXPort.java: System.loadLibrary( "rxtxSerial" ); /usr/src/rxtx/rxtx-2.1-7/src/RXTXVersion.java: System.loadLibrary( "rxtxSerial" ); -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Fri May 23 20:30:51 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 23 May 2008 22:30:51 -0400 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48362235.5020604@ergotech.com> References: <48362235.5020604@ergotech.com> Message-ID: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Are you explictily doing anything with the might use a different class loader? Also is should be noted that the folowing clases uses a class initializer ( static {} ) to load the rxtx native library: - RXTXVersion.java - LPRPort.java - CommPortIdentifier.java This means we have three places trying to load the native library, whether the classes are used or not, which I am not sure is such a good thing. Ideally we should limit this to one class and make it on demand if possible (think singleton). Andre On 22-May-08, at 21:47 , Jim Redman wrote: > RXTX Gurus, > > OK, this is (hopefully) my last barrier to having RXTX running under > Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. > > This all runs correctly on FC8. Any pointers/suggestions appreciated. > > The application gets to the point where it starts to access serial > ports > and I get this: > > Experimental: JNI_OnLoad called. > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader thrown while loading > gnu.io.RXTXCommDriver > > Unhandled Exception: System.TypeInitializationException: An exception > was thrown by the type initializer for gnu.io.CommPortIdentifier ---> > java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so > already loaded in another classloader--- End of inner exception stack > trace --- > > at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] > > The native libraries in play are: > > libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), > not stripped > > > Thanks, > > Jim > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat May 24 09:10:20 2008 From: jredman at ergotech.com (Jim Redman) Date: Sat, 24 May 2008 09:10:20 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <48382FDC.50208@ergotech.com> Andre, Thanks for the hints. This certainly doesn't seem good. However, even if I take the native library load out of RXTXVersion the problem persists. At this point, it would seem to be a mono/IKVM problem on ARM. The same code appears to load correctly on x86 - FC8 and Ubuntu. Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gultor at gmail.com Sat May 24 20:08:50 2008 From: gultor at gmail.com (Gultor) Date: Sun, 25 May 2008 09:08:50 +0700 Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() Message-ID: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Dear Guys, I'm trying to call method getPortIdentifier() but the response is very slow :( Here is my code: System.out.println("Identify port.."); CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); SerialPort port = (SerialPort) portId.open("deviceId", 2000); System.out.println("OK"); The application just stop after print: "Native lib Version = RXTX-2.1-7" "Java lib Version = RXTX-2.1-7" "Identify port.." What's wrong? Please help.. I'm using jdk 1.6 on windows XP home edition. Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080525/9f0f5583/attachment-0028.html From tjarvi at qbang.org Sat May 24 20:39:10 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 24 May 2008 20:39:10 -0600 (MDT) Subject: [Rxtx] [ask] response very slow when call getPortIdentifier() In-Reply-To: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> References: <8cfcd20a0805241908g5e2a7197q9f1e5d0b014da35f@mail.gmail.com> Message-ID: On Sun, 25 May 2008, Gultor wrote: > Dear Guys, > > I'm trying to call method getPortIdentifier() but the response is very slow > :( > > Here is my code: > > System.out.println("Identify port.."); > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier("COM37"); > SerialPort port = (SerialPort) portId.open("deviceId", 2000); > System.out.println("OK"); > > > The application just stop after print: > "Native lib Version = RXTX-2.1-7" > "Java lib Version = RXTX-2.1-7" > "Identify port.." > > What's wrong? > Please help.. > > I'm using jdk 1.6 on windows XP home edition. > > Thank you very much. > I've not noticed a slow enumeration. How many serial ports do you have? What rxtx does is try to open each port from 1-256 and does a timed out ready. If you have many ports, it may make more sense to use the properties files to specify which ports you want to use. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Sun May 25 08:30:34 2008 From: jredman at ergotech.com (Jim Redman) Date: Sun, 25 May 2008 08:30:34 -0600 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> Message-ID: <4839780A.8060104@ergotech.com> A very nice workaround from Jeroen Frijters over on the IKVM list. This might apply to other ARM systems, so I'll post it here in case it's useful. The essence of the solution is to change System.loadLibrary("rxtxSerial"); to: Runtime.getRuntime().loadLibrary(libname, RXTXCommDriver.class.getClassLoader()); so the classloader is specified. The loadLibrary method of Runtime is inaccessible and may have different names/signatures, etc. on different JVM implementations. Calling it by reflection, you end up with code something like this: try { java.lang.reflect.Method m = Runtime.class.getDeclaredMethod("loadLibrary", new Class[] {String.class, ClassLoader.class}); m.setAccessible(true); m.invoke(Runtime.getRuntime(), new Object[] {"rxtxSerial", RXTXCommDriver.class.getClassLoader()}); } catch ( Exception any ) { any.printStackTrace(); } Thanks again for the help of the lists, Jim Andre-John Mas wrote: > Are you explictily doing anything with the might use a different class > loader? > > Also is should be noted that the folowing clases uses a class initializer > ( static {} ) to load the rxtx native library: > > - RXTXVersion.java > - LPRPort.java > - CommPortIdentifier.java > > This means we have three places trying to load the native library, > whether the > classes are used or not, which I am not sure is such a good thing. > Ideally we > should limit this to one class and make it on demand if possible (think > singleton). > > Andre > > On 22-May-08, at 21:47 , Jim Redman wrote: > >> RXTX Gurus, >> >> OK, this is (hopefully) my last barrier to having RXTX running under >> Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. >> >> This all runs correctly on FC8. Any pointers/suggestions appreciated. >> >> The application gets to the point where it starts to access serial ports >> and I get this: >> >> Experimental: JNI_OnLoad called. >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader thrown while loading >> gnu.io.RXTXCommDriver >> >> Unhandled Exception: System.TypeInitializationException: An exception >> was thrown by the type initializer for gnu.io.CommPortIdentifier ---> >> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so >> already loaded in another classloader--- End of inner exception stack >> trace --- >> >> at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] >> >> The native libraries in play are: >> >> libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), >> not stripped >> >> >> Thanks, >> >> Jim >> >> -- >> Jim Redman >> (505) 662 5156 x85 >> http://www.ergotech.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Sun May 25 10:55:04 2008 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 25 May 2008 11:55:04 -0500 Subject: [Rxtx] already loaded in another classloader In-Reply-To: <48382FDC.50208@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> Message-ID: <483999E8.30000@cox.net> Jim Redman wrote: > Andre, > > Thanks for the hints. > > This certainly doesn't seem good. However, even if I take the native > library load out of RXTXVersion the problem persists. > > At this point, it would seem to be a mono/IKVM problem on ARM. The same > code appears to load correctly on x86 - FC8 and Ubuntu. The most trivial way to solve this is to add the logging of a "Throwable" created in the places that the library is loaded. In the log message, include the Thread.currentThread() value and the getClass().getClassLoader() value so that you can see who is doing what, when. Gregg Wonderly From peuchele at hotmail.com Mon May 26 20:48:04 2008 From: peuchele at hotmail.com (Fernando Vicente) Date: Mon, 26 May 2008 23:48:04 -0300 Subject: [Rxtx] Code suggestion Message-ID: Hi, First of all thanks for this great library!!! I have a small suggestion to optimize the readArray and writeArray functions in ParallelImp.c. This is a summary of how the code looks today in readArray function: buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); ... bytes = read_byte_array( fd, buffer, length, threshold, timeout ); ... for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; free( buffer ); In C we can increment the output buffer pointer to the position we want to start to write (offset) directly, avoiding the necessity of allocating a new buffer and copying the contents, for example: //buffer = (unsigned char *)malloc( sizeof( unsigned char ) * length ); buffer = body+offset bytes = read_byte_array( fd, buffer, length, threshold, timeout ); //for( i = 0; i < bytes; i++ ) body[ i + offset ] = buffer[ i ]; //free( buffer ); the same kind of optimization can be also applied to the writeArray function in the same source file. Hope this helps! Fernando Vicente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080526/67aeeb05/attachment-0026.html From Loi.TRAN at weatherford.com Tue May 27 08:58:54 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 09:58:54 -0500 Subject: [Rxtx] Avoiding delays between characters sent. In-Reply-To: References: Message-ID: > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Friday, May 23, 2008 8:35 PM > To: TRAN, Loi X. > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Avoiding delays between characters sent. > > On Fri, 23 May 2008, TRAN, Loi X. wrote: > >> We're attempting to use a Silicon Labs part number CP2103 which looks >> like a RS232 port. The part itself is a USB port. It's currently run >> at 460.8Kbaud. Using the class below, we sent out an array of bytes of >> length defined by what's passed in. We have a problem in that the data >> being sent out of the USB port has wide gaps in time (~20 - 30 >> milliseconds) between each byte sent. How can we force the bytes to be >> burst out with minimal delay (<5 ms) between each byte? Has anyone >> experienced this problem? >> >> import java.io.IOException; >> import java.io.OutputStream; >> >> public class SerialWriter implements Runnable >> { >> private OutputStream out; >> private int count; >> private byte[] c; >> >> public SerialWriter ( OutputStream out, byte[] c ) >> { >> this.out = out; >> this.c = c; >> } >> >> public void run () >> { >> try >> { >> for (count = 0; count < c.length; count++) >> out.write(c[count]); >> } >> catch (IOException e) >> { >> e.printStackTrace(); >> } >> } >> } >> > > The operating system can be busy for 8-10 ms between each write above. > I'd recommend sending the array of bytes to write and let the lower level > code handle it. The more that is done in the kernel, the better. > > Beyond that, you may need to modify the native code to accept larger > arrays and handle the writes without jumping between layers in the driver. > -- > Trent Jarvi > tjarvi at qbang.org The following change helped immensely: try { //for (count = 0; count < c.length; count++) // out.write(c[count]); out.write(c); } Thanks to Trent's suggestion. LT =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From rcolmegna at tiscali.it Tue May 27 09:09:35 2008 From: rcolmegna at tiscali.it (rcolmegna at tiscali.it) Date: Tue, 27 May 2008 17:09:35 +0200 (CEST) Subject: [Rxtx] RXTX problem on linux Message-ID: <19182193.1211900975418.JavaMail.root@ps10> hi, I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. I have this small app: ------ import javax.comm.*; import java.io.*; import java.util.*; public class SMS { public static void main(String[] ap) { Enumeration pList = CommPortIdentifier.getPortIdentifiers(); while (pList.hasMoreElements()) { CommPortIdentifier cpi = (CommPortIdentifier) pList. nextElement(); System.out.print("Port " + cpi.getName() + " "); if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("is a Serial Port: " + cpi); } else if (cpi.getPortType() == CommPortIdentifier. PORT_PARALLEL) { System.out.println("is a Parallel Port: " + cpi); } else { System.out.println("is an Unknown Port: " + cpi); } } } } --- but when I execute it I obtain this error: --- Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. java:239) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:109) at SMS.main(SMS.java:7) Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. comm.SunrayInfo.isSessionActive()Z at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: 155) at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. java:100) at javax.comm.CommPortIdentifier.(CommPortIdentifier. java:138) at SMS.main(SMS.java:7) --- If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use export LD_LIBRARY_PATH=// on my run script) Any suggests? TIA ___________________________________________________ Migliaia di prodotti nuovi e usati a partire da 1 euro! http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 From Loi.TRAN at weatherford.com Tue May 27 16:02:38 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Tue, 27 May 2008 17:02:38 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) Message-ID: I've implemented the following receiver thread: import java.io.InputStream; import java.io.IOException; public class SerialReader implements Runnable { // constants final int BYTE_BUFFER_MAX = 256; final int BUFFER_MAX = 256; final long INITIAL_INACTIVE_PERIOD = 2000; final long QUALIFY_INACTIVE_PERIOD = 5; // variables private InputStream in; private long msLastActive; private long msCurr; private long inactivePeriod; private int state; private int index; private int iLen; private int bLen; private long initialWaitPeriod; private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; int[] buffer = new int[BUFFER_MAX]; // constructors public SerialReader (InputStream in) { this.in = in; this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public SerialReader (InputStream in, long initialWaitPeriod) { this.in = in; this.initialWaitPeriod = initialWaitPeriod; bLen = 0; iLen = 0; state = 0; //for (index = 0; index < BUFFER_MAX; index++) // buffer[index] = -1; index = 0; msLastActive = 0; msCurr = 0; inactivePeriod = 0; } public int getBufferLength () { return iLen; } // thread public void run () { while (state != -1) { switch (state) { case 0: msLastActive = System.currentTimeMillis(); state = 1; case 1: // initial stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > initialWaitPeriod) state = -1; } else { // set initial active time msLastActive = System.currentTimeMillis(); for (iLen = 0; iLen < bLen; iLen++) buffer[iLen] = bBuffer[iLen]; state = 2; } break; case 2: // stream in reading try { bLen = in.read (bBuffer); } catch (IOException e) { e.printStackTrace(); } if (bLen == 0 || bLen == -1) { msCurr = System.currentTimeMillis(); inactivePeriod = msCurr - msLastActive; if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) state = -1; } else { // set latest active time msLastActive = System.currentTimeMillis(); for (index = 0; index < bLen; iLen++, index++) buffer[iLen] = bBuffer[index]; } break; case -1: default: state = -1; } } } } I know it looks atrocious, but it's my first attempt at writing code in Java. It works. The problem is that it works very slowly. The time it takes for the thread to complete from testing is about 500ms. This is longer than desired considering that I have to receive about 8000 messages. Each message is very small (76-78 bytes). It would take over an hour to send about 600Kbytes. That's unacceptable. It's used like so in my main thread. sr = new SerialReader (in); sw = new SerialWriter (out, pkt); // send page packet and wait for response t0 = new Thread (sr); t1 = new Thread (sw); t0.start(); t1.start(); System.out.println ("Receive start " + System.currentTimeMillis()); try { t0.join (); //t1.join (); } catch (InterruptedException e) { System.out.println (":: Interrupted thread"); } System.out.println ("Receive finish " + System.currentTimeMillis()); My first question is "What is it doing that's taking so long for the thread to complete?" The second question is, "Should I be doing this with events." I don't want to go through all the trouble of writing event handling and have it turn out producing pretty much the same result as what I'm currently doing. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From johnny.luong at trustcommerce.com Tue May 27 16:04:01 2008 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Tue, 27 May 2008 15:04:01 -0700 Subject: [Rxtx] RXTX problem on linux In-Reply-To: <19182193.1211900975418.JavaMail.root@ps10> References: <19182193.1211900975418.JavaMail.root@ps10> Message-ID: <483C8551.8000709@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try changing your "import javax.comm.*;" to "import gnu.io.*;", recompile it, and see if it runs... I think you have to be using rxtx 2.0 in order to use the javax.comm namespace. Best, Johnny rcolmegna at tiscali.it wrote: | hi, | | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. | | I have this small app: | ------ | import javax.comm.*; | import java.io.*; | import java.util.*; | | public class SMS { | public static void main(String[] ap) { | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); | while (pList.hasMoreElements()) { | CommPortIdentifier cpi = (CommPortIdentifier) pList. | nextElement(); | System.out.print("Port " + cpi.getName() + " "); | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { | System.out.println("is a Serial Port: " + cpi); | } else if (cpi.getPortType() == CommPortIdentifier. | PORT_PARALLEL) { | System.out.println("is a Parallel Port: " + cpi); | } else { | System.out.println("is an Unknown Port: " + cpi); | } | } | } | } | --- | | but when I execute it I obtain this error: | --- | Experimental: JNI_OnLoad called. | Stable Library | ========================================= | Native lib Version = RXTX-2.1-7 | Java lib Version = RXTX-2.1-7 | | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. | java:239) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:109) | at SMS.main(SMS.java:7) | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. | comm.SunrayInfo.isSessionActive()Z | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: | 155) | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. | java:100) | at javax.comm.CommPortIdentifier.(CommPortIdentifier. | java:138) | at SMS.main(SMS.java:7) | --- | | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use | export LD_LIBRARY_PATH=// on my run script) | | Any suggests? | | TIA | | | | ___________________________________________________ | | | Migliaia di prodotti nuovi e usati a partire da 1 euro! | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 | | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz AEsEFV3UMSiLfODD3OTM =visR -----END PGP SIGNATURE----- From jredman at ergotech.com Tue May 27 18:13:39 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 27 May 2008 18:13:39 -0600 Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483999E8.30000@cox.net> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> Message-ID: <483CA3B3.8030901@ergotech.com> These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for pointing the way. They appear to be genuine bugs, not artifacts of the platform. SerialImp.c:1533 calls get_java_var with these args: struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); so a request for a Long value. But if you look at get_java_var, the only call is to "GetIntField", line 4892: result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); This causes an error on IKVM, probably rightly so, there is an implicit cast of a long to an int. The twin to this bug is line 1338 where there is a "SetIntField" against a long: jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); The fix for the SetIntField is obvious, change to SetLongField. However the fix for get_java_var is not so obvious. As far as I can tell, get_java_var is called only with "I" and "J", so as a quick hack, I check for those two and that seems to work. Presumably shorter type ("B", "C", "S") would work, but the char *type is unbounded and so prone to errors. I would propose a couple of choices to start the discussion: 1) Rename get_java_var to get_java_int (or similar) and drop the char *type argument. Create get_java_long, which is the same as get_java_int, except that it uses GetLongField. Some significant refactoring, but would also work for doubles, arrays, etc. 2) Make get_java_var work for longs and ints and make it throw for all other types. Longs and ints are the only types currently in use. Any thoughts? Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Tue May 27 19:10:09 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:10:09 -0600 (MDT) Subject: [Rxtx] RXTX problem on linux In-Reply-To: <483C8551.8000709@trustcommerce.com> References: <19182193.1211900975418.JavaMail.root@ps10> <483C8551.8000709@trustcommerce.com> Message-ID: That is correct. RXTX 2.0 + javax.comm 2.0 work together in the javax.comm namespace through a service provider interface (SPI). I would not recommend using javax.comm namespace at this point. If the rxtx community and Sun agree to what that might look like in the future it might be a valid option. Current releases of Sun's API no longer support the SPI - a honest miststep. I don't think anyone has the time to work out the details and future rxtx releases will not include 2.0 updates - though 2.1 will be licensed in a way that anyone can hack a 2.0 release together (see the linking over controlled interfaces exception). This is the best we can do under a difficult situation. On Tue, 27 May 2008, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Try changing your "import javax.comm.*;" to "import gnu.io.*;", > recompile it, and see if it runs... I think you have to be using rxtx > 2.0 in order to use the javax.comm namespace. > > > Best, > Johnny > > rcolmegna at tiscali.it wrote: > | hi, > | > | I'm trying RXTX on a linux 2.6.20krn and jdk 1.6.0-b105. > | > | I have this small app: > | ------ > | import javax.comm.*; > | import java.io.*; > | import java.util.*; > | > | public class SMS { > | public static void main(String[] ap) { > | Enumeration pList = CommPortIdentifier.getPortIdentifiers(); > | while (pList.hasMoreElements()) { > | CommPortIdentifier cpi = (CommPortIdentifier) pList. > | nextElement(); > | System.out.print("Port " + cpi.getName() + " "); > | if (cpi.getPortType() == CommPortIdentifier.PORT_SERIAL) { > | System.out.println("is a Serial Port: " + cpi); > | } else if (cpi.getPortType() == CommPortIdentifier. > | PORT_PARALLEL) { > | System.out.println("is a Parallel Port: " + cpi); > | } else { > | System.out.println("is an Unknown Port: " + cpi); > | } > | } > | } > | } > | --- > | > | but when I execute it I obtain this error: > | --- > | Experimental: JNI_OnLoad called. > | Stable Library > | ========================================= > | Native lib Version = RXTX-2.1-7 > | Java lib Version = RXTX-2.1-7 > | > | java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > | gnu.io.RXTXCommDriver cannot be cast to javax.comm.CommDriver > | at javax.comm.CommPortIdentifier.loadDriver(CommPortIdentifier. > | java:239) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:109) > | at SMS.main(SMS.java:7) > | Exception in thread "main" java.lang.UnsatisfiedLinkError: com.sun. > | comm.SunrayInfo.isSessionActive()Z > | at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > | at com.sun.comm.Portmapping.registerCommPorts(Portmapping.java: > | 155) > | at com.sun.comm.Portmapping.refreshPortDatabase(Portmapping. > | java:100) > | at javax.comm.CommPortIdentifier.(CommPortIdentifier. > | java:138) > | at SMS.main(SMS.java:7) > | --- > | > | If I use "strace" I note that librxtxSerial.so ISN'T loaded (I use > | export LD_LIBRARY_PATH=// on my run script) > | > | Any suggests? > | > | TIA > | > | > | > | ___________________________________________________ > | > | > | Migliaia di prodotti nuovi e usati a partire da 1 euro! > | http://rover.ebay.com/rover/1/724-7199-4110-179/4/?id=2 > | > | _______________________________________________ > | Rxtx mailing list > | Rxtx at qbang.org > | http://mailman.qbang.org/mailman/listinfo/rxtx > | > | > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQIcBAEBAgAGBQJIPIVMAAoJEJdI1jIpgaUDtlUQAJ0wOzgCaxnevuyO2fqBLjwq > 5nKhnA4c1X/V0mJWzGXYWaC4YE7zG2mKG7Ih5bJ4n7gP6NUiRwAA0stvCHSTpsoD > epfjUYLpmZyZxHyvyCb6wYSsEd3NabMK8Ew6K0VazNUVnT4srFY4d1tG2qz5bJc+ > jdRn8gSjXS0qGDywaMTag91jKUjcnpaPFRqtdnXZs1Fg0X8/UmrkGHsbuDj/mVwu > Mlml8KCND3CSpoScRnv9ijanoAsHAU8ZdBrCllhKIcWs80875M7WaVcnLeri6Rhq > 1abomVmZAIUAW8z2rvL1xYFajicwgLDmF+jzX8Q5tIxOz4RVty7IJmUTeY0Mvr/F > J4SamFKBd5B5cco9s0WIgGH59Lz0tnXpk8XRr0OpR/e1MgTn51QczXm8R5ptonKN > W/V478jTjsif8FkR6LX9oDH1UBEquVpbH+PX3LmRqH9FJ4wXF0v6U3irEHW0Xd+0 > cRuSfEI4uFA8ac69mhr4avPuN9aFoAv3j6vLuU9RLqV4YFD4DMePuRJyVlBQ4xCe > OIacasVicB5HDH2xTbZ37geUXWBsGRjuOK5S1SoCjTt+mFhOsvbIZqjYBoCnOSpD > s4Hl3mjOpfB5x+i0jek6BH7YluZQpBNlwI1jTvL6WpSQXSiVHu09bj2UeXfogWwz > AEsEFV3UMSiLfODD3OTM > =visR > -----END PGP SIGNATURE----- > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue May 27 19:49:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:49:06 -0600 (MDT) Subject: [Rxtx] SerialImp.c Bugs In-Reply-To: <483CA3B3.8030901@ergotech.com> References: <48362235.5020604@ergotech.com> <2F166426-7FB0-4A91-BC9B-CDA2CC044147@sympatico.ca> <48382FDC.50208@ergotech.com> <483999E8.30000@cox.net> <483CA3B3.8030901@ergotech.com> Message-ID: On Tue, 27 May 2008, Jim Redman wrote: > These bugs seem to show up on ARM/IKVM. Thanks again to Jeroen for > pointing the way. They appear to be genuine bugs, not artifacts of the > platform. > > SerialImp.c:1533 calls get_java_var with these args: > > struct event_info_struct *eis = ( struct event_info_struct * ) > get_java_var( env, jobj, "eis", "J" ); > > so a request for a Long value. > > But if you look at get_java_var, the only call is to "GetIntField", line > 4892: > > result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); > > This causes an error on IKVM, probably rightly so, there is an implicit > cast of a long to an int. > > > The twin to this bug is line 1338 where there is a "SetIntField" against > a long: > > jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); > report("init_threads: set eis\n"); > (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); > > The fix for the SetIntField is obvious, change to SetLongField. However > the fix for get_java_var is not so obvious. As far as I can tell, > get_java_var is called only with "I" and "J", so as a quick hack, I > check for those two and that seems to work. > > Presumably shorter type ("B", "C", "S") would work, but the char *type > is unbounded and so prone to errors. > > I would propose a couple of choices to start the discussion: > > 1) Rename get_java_var to get_java_int (or similar) and drop the char > *type argument. Create get_java_long, which is the same as > get_java_int, except that it uses GetLongField. Some significant > refactoring, but would also work for doubles, arrays, etc. > > 2) Make get_java_var work for longs and ints and make it throw for all > other types. Longs and ints are the only types currently in use. > Nice Jim, Either way would be fine. I like function names that suggest what they do. I'd suggest putting a patch together that works for arm and we can try it on other systems. Notably, the eis pointer needs to be saved as a long for 64 bit systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue May 27 19:55:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 27 May 2008 19:55:02 -0600 (MDT) Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: On Tue, 27 May 2008, TRAN, Loi X. wrote: > I've implemented the following receiver thread: > > import java.io.InputStream; > import java.io.IOException; > > public class SerialReader implements Runnable > { > // constants > final int BYTE_BUFFER_MAX = 256; > final int BUFFER_MAX = 256; > final long INITIAL_INACTIVE_PERIOD = 2000; > final long QUALIFY_INACTIVE_PERIOD = 5; > > // variables > private InputStream in; > private long msLastActive; > private long msCurr; > private long inactivePeriod; > private int state; > private int index; > private int iLen; > private int bLen; > private long initialWaitPeriod; > private byte[] bBuffer = new byte[BYTE_BUFFER_MAX]; > int[] buffer = new int[BUFFER_MAX]; > > // constructors > public SerialReader (InputStream in) > { > this.in = in; > this.initialWaitPeriod = INITIAL_INACTIVE_PERIOD; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public SerialReader (InputStream in, long initialWaitPeriod) > { > this.in = in; > this.initialWaitPeriod = initialWaitPeriod; > bLen = 0; > iLen = 0; > state = 0; > //for (index = 0; index < BUFFER_MAX; index++) > // buffer[index] = -1; > index = 0; > msLastActive = 0; > msCurr = 0; > inactivePeriod = 0; > } > > public int getBufferLength () > { > return iLen; > } > > // thread > public void run () > { > while (state != -1) > { > switch (state) > { > case 0: > msLastActive = System.currentTimeMillis(); > state = 1; > > case 1: > // initial stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > initialWaitPeriod) > state = -1; > } > else > { > // set initial active time > msLastActive = System.currentTimeMillis(); > for (iLen = 0; iLen < bLen; iLen++) > buffer[iLen] = bBuffer[iLen]; > state = 2; > } > break; > > case 2: > // stream in reading > try > { > bLen = in.read (bBuffer); > } > catch (IOException e) > { > e.printStackTrace(); > } > > if (bLen == 0 || bLen == -1) > { > msCurr = System.currentTimeMillis(); > inactivePeriod = msCurr - msLastActive; > if (inactivePeriod > QUALIFY_INACTIVE_PERIOD) > state = -1; > } > else > { > // set latest active time > msLastActive = System.currentTimeMillis(); > > for (index = 0; index < bLen; iLen++, index++) > buffer[iLen] = bBuffer[index]; > } > break; > > case -1: > default: > state = -1; > } > } > } > } > > I know it looks atrocious, but it's my first attempt at writing code in > Java. It works. The problem is that it works very slowly. The time it > takes for the thread to complete from testing is about 500ms. This is > longer than desired considering that I have to receive about 8000 > messages. Each message is very small (76-78 bytes). It would take over > an hour to send about 600Kbytes. That's unacceptable. It's used like > so in my main thread. > > sr = new SerialReader (in); > sw = new SerialWriter (out, pkt); > // send page packet and wait for response > t0 = new Thread (sr); > t1 = new Thread (sw); > t0.start(); > t1.start(); > System.out.println ("Receive start " + System.currentTimeMillis()); > try > { > t0.join (); > //t1.join (); > } > catch (InterruptedException e) > { > System.out.println (":: Interrupted thread"); > } > System.out.println ("Receive finish " + System.currentTimeMillis()); > > My first question is "What is it doing that's taking so long for the > thread to complete?" The second question is, "Should I be doing this > with events." I don't want to go through all the trouble of writing > event handling and have it turn out producing pretty much the same > result as what I'm currently doing. > Your read thread is going to race. You can either use event notification or just Thread.sleep() to allow the system to read some data. Given that ever read call is probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. You can look at the bytes available and decide if you want to read or sleep. Try looking at your CPU use. The application should not take 1% of the CPU while reading full speed. I suspect your code is using more like 80%. -- Trent Jarvi tjarvi at qbang.org From Loi.TRAN at weatherford.com Wed May 28 08:32:05 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Wed, 28 May 2008 09:32:05 -0500 Subject: [Rxtx] Receive thread completion takes a long time (~500 ms) In-Reply-To: References: Message-ID: -----Original Message----- From: Trent Jarvi [mailto:tjarvi at qbang.org] Sent: Tuesday, May 27, 2008 8:55 PM To: TRAN, Loi X. Cc: rxtx at qbang.org Subject: Re: [Rxtx] Receive thread completion takes a long time (~500 ms) > Your read thread is going to race. You can either use event notification or just > > > > > Thread.sleep() to allow the system to read some data. Given that ever read call is > > > > probably going to take 8-10 ms, try sleeping for 5 ms in your loop and go from there. > > > You can look at the bytes available and decide if you want to read or sleep. > > Try looking at your CPU use. The application should not take 1% of the CPU while reading > full speed. I suspect your code is using more like 80%. > > -- > Trent Jarvi > tjarvi at qbang.org I've tried putting the thread to sleep with no effect. I don't believe thread race is the problem. I've looked at the CPU utilization and the highest I've seen it peak is 3%. It's mostly at 1%. Something I'd forgotten to add in my prior post is that I've used this receiver threading successfully at 57.6 Kbps. It's only after we switched to the higher speed 460.8 Kbps USB serial port that I'm now seeing this problem. At 57.6Kbps, the thread took ~20ms to completely end which confused me at the time, but still tolerable. It seems to be greatly exaggerated at the higher speeds. Thanks for the help. I think I'll have to implement event notification to see if we'll get more tolerable performance. We'll see how it goes. Loi =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the consequences of any unauthorized use, of this communication or message. From taylorb at gmail.com Thu May 29 08:37:25 2008 From: taylorb at gmail.com (Taylor Bayouth) Date: Thu, 29 May 2008 07:37:25 -0700 Subject: [Rxtx] Trip Tracker Message-ID: <583283d00805290737i5274fb0bxa711d2199864f71d@mail.gmail.com> I am looking for the team responsible for the Java package "Trip Tracker". I was told that one or some of the developers that created the package might still receive messages from this list. If you have any information please send it my way. I am hoping to hire someone to help me modify the package to fit my needs. THANK YOU! -Taylor From avandyck at gmail.com Fri May 30 01:37:56 2008 From: avandyck at gmail.com (Arnaud Vandyck) Date: Fri, 30 May 2008 09:37:56 +0200 Subject: [Rxtx] Rxtx on mac os x Message-ID: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Hi all, [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - arch patch in the Makefile etc) I'm new to rxtx. I need it to read barcodes from an usb barcode reader (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but the connector is usb (as you can see, I'm new also in using barcode reader and rs232 comm etc) ;-) If I do: $ cat /dev/cu.usbmodem1a21 I can see the code bare when I scan something. If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports I have this output: Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Port, /dev/tty.usbmodem1a21, is in use. Port, /dev/cu.usbmodem1a21, is in use. Port, /dev/tty.Bluetooth-Modem, is in use. Port, /dev/cu.Bluetooth-Modem, is in use. Port, /dev/tty.Bluetooth-PDA-Sync, is in use. Port, /dev/cu.Bluetooth-PDA-Sync, is in use. If I try the SimpleRead example from Sun, I have an PortAlreadyInUseException. Does someone knows if there is something special to shutdown or to configure to be able to read the barcode reader on Mac OS X? Thanks for your help, -- Arnaud Vandyck avandyck at gmail.com From zach at sensinode.com Fri May 30 02:33:23 2008 From: zach at sensinode.com (Zach Shelby) Date: Fri, 30 May 2008 11:33:23 +0300 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> Message-ID: <483FBBD3.9030302@sensinode.com> Hi, I had this same problem. You need to make a directory /var/lock instead of /var/spool/uucp (which doesn't help). There is an error in the 2.1.7r2 installation instructions regarding /var/spool/uucp. In the next release that should be updated to /var/lock (is this only for 10.5 and newer?). Give it the chmod permissions as in the instructions and add yourself as a uucp and lock group member. With 10.5.2 niutil no longer works, so you need to add yourself to the group using dscl (google it). This also needs an update in the installation instruction. - Zach Arnaud Vandyck wrote: > Hi all, > > [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - > arch patch in the Makefile etc) > > I'm new to rxtx. I need it to read barcodes from an usb barcode reader > (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, but > the connector is usb (as you can see, I'm new also in using barcode > reader and rs232 comm etc) ;-) > > If I do: > $ cat /dev/cu.usbmodem1a21 > > I can see the code bare when I scan something. > > If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports > > I have this output: > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Port, /dev/tty.usbmodem1a21, is in use. > Port, /dev/cu.usbmodem1a21, is in use. > Port, /dev/tty.Bluetooth-Modem, is in use. > Port, /dev/cu.Bluetooth-Modem, is in use. > Port, /dev/tty.Bluetooth-PDA-Sync, is in use. > Port, /dev/cu.Bluetooth-PDA-Sync, is in use. > > If I try the SimpleRead example from Sun, I have an > PortAlreadyInUseException. > > Does someone knows if there is something special to shutdown or to > configure to be able to read the barcode reader on Mac OS X? > > Thanks for your help, > > -- > Arnaud Vandyck > avandyck at gmail.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From ehjuerrens at uni-muenster.de Fri May 30 09:38:04 2008 From: ehjuerrens at uni-muenster.de (=?ISO-8859-15?Q?Eike_Hinderk_J=FCrrens?=) Date: Fri, 30 May 2008 17:38:04 +0200 Subject: [Rxtx] Problems with some Serialports using Windows Message-ID: <48401F5C.7090509@uni-muenster.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is my first post on this mailing list. I am using rxtx to access a home weather station (=hws) from ELV (a german company: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). I developed the software using linux and there were no problems. Now I "installed" my program on Windows XP and with some machines I have heavy problems but others doing a good job. I can not figure out the source of the problem because there are no exceptions thrown. The only problem is that the hws is not answering correctly or answering not at all to my calls. I have to activate the communication with the hws sending as often as possible a special byte pattern and wait for an ACK by the station. On the problematic windows machines I am receiving an ACK but when I send a command pattern I still receive the ACK. Do you have any idea how to narrow the problem? Do you need some LOC? What additional information do you need? Thanks for your help Eike Hinderk J?rrens - -- http://ifgi.uni-muenster.de/~e_juer01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIQB9c820dQiNIWckRAsckAJ41oFmhsfKFOtOsxYf65jqGKepvrgCfZoyy v4jB3giFqflmmgQ0TsjzXVY= =iw/8 -----END PGP SIGNATURE----- From ajmas at sympatico.ca Fri May 30 18:59:07 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 30 May 2008 20:59:07 -0400 Subject: [Rxtx] Rxtx on mac os x In-Reply-To: <483FBBD3.9030302@sensinode.com> References: <0D43D123-1D8C-48FF-BEBD-69670E0F27AF@gmail.com> <483FBBD3.9030302@sensinode.com> Message-ID: <2EC97E30-5E3A-4177-AA06-610E7D18A627@sympatico.ca> Hi, Another approach is to try the version from CVS, which does not require lock files. Andre On 30-May-08, at 04:33 , Zach Shelby wrote: > Hi, > > I had this same problem. You need to make a directory /var/lock > instead > of /var/spool/uucp (which doesn't help). There is an error in the > 2.1.7r2 installation instructions regarding /var/spool/uucp. In the > next > release that should be updated to /var/lock (is this only for 10.5 and > newer?). > > Give it the chmod permissions as in the instructions and add > yourself as > a uucp and lock group member. With 10.5.2 niutil no longer works, so > you > need to add yourself to the group using dscl (google it). This also > needs an update in the installation instruction. > > - Zach > > Arnaud Vandyck wrote: >> Hi all, >> >> [Mac OS X 10.5.2; Java 1.5.0_13; RXTX 2.1.7r2 (recompiled with the - >> arch patch in the Makefile etc) >> >> I'm new to rxtx. I need it to read barcodes from an usb barcode >> reader >> (datalogic's heron). It must be SERIAL_PORT (or RS232) configured, >> but >> the connector is usb (as you can see, I'm new also in using barcode >> reader and rs232 comm etc) ;-) >> >> If I do: >> $ cat /dev/cu.usbmodem1a21 >> >> I can see the code bare when I scan something. >> >> If I try http://rxtx.qbang.org/wiki/index.php/Discovering_available_comm_ports >> >> I have this output: >> Experimental: JNI_OnLoad called. >> Stable Library >> ========================================= >> Native lib Version = RXTX-2.1-7 >> Java lib Version = RXTX-2.1-7 >> Port, /dev/tty.usbmodem1a21, is in use. >> Port, /dev/cu.usbmodem1a21, is in use. >> Port, /dev/tty.Bluetooth-Modem, is in use. >> Port, /dev/cu.Bluetooth-Modem, is in use. >> Port, /dev/tty.Bluetooth-PDA-Sync, is in use. >> Port, /dev/cu.Bluetooth-PDA-Sync, is in use. >> >> If I try the SimpleRead example from Sun, I have an >> PortAlreadyInUseException. >> >> Does someone knows if there is something special to shutdown or to >> configure to be able to read the barcode reader on Mac OS X? >> >> Thanks for your help, >> >> -- >> Arnaud Vandyck >> avandyck at gmail.com >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > Zach Shelby | Head of Research | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri May 30 19:21:53 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 30 May 2008 19:21:53 -0600 (MDT) Subject: [Rxtx] Problems with some Serialports using Windows In-Reply-To: <48401F5C.7090509@uni-muenster.de> References: <48401F5C.7090509@uni-muenster.de> Message-ID: On Fri, 30 May 2008, Eike Hinderk J?rrens wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > this is my first post on this mailing list. > > I am using rxtx to access a home weather station (=hws) from ELV (a > german company: > http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=9096). > > I developed the software using linux and there were no problems. > > Now I "installed" my program on Windows XP and with some machines I have > heavy problems but others doing a good job. I can not figure out the > source of the problem because there are no exceptions thrown. The only > problem is that the hws is not answering correctly or answering not at > all to my calls. > I have to activate the communication with the hws sending as often as > possible a special byte pattern and wait for an ACK by the station. > On the problematic windows machines I am receiving an ACK but when I > send a command pattern I still receive the ACK. > > Do you have any idea how to narrow the problem? > > Do you need some LOC? > Some LOC may help. You may look to see that you have read all the data and are not reading a previous response from the device. Are you using events? I recall a difference in the frequency of one event (data available? output buffer empty?) Is any flow control involved? Linux will usually just do the right thing while you need to be explicit on windows. -- Trent Jarvi tjarvi at qbang.org From manueldarveau at gmail.com Fri May 2 10:29:25 2008 From: manueldarveau at gmail.com (Manuel Darveau) Date: Fri, 2 May 2008 12:29:25 -0400 Subject: [Rxtx] Bug report (no break event, no data event when read is blocked, read return -1 in windows) Message-ID: Hi all! First of all, thank you very much for the rxtx implementation. The JavaCom is a pain to use and the gnu.io version of rxtx really make things easier especially for deployment. However, I had a couple of issue when switching from sun's JavaCom (on window) and rxtx javax.comm compatible version (on linux) to the new gnu.ioversion on both platform. 1 - On window, calling inputstream.read() in a loop will always return -1 instead of blocking the call. This may be an acceptable behaviour (altough it break the InputStream contract of returning -1 only on end of stream) but it is nevertheless different that the two other implementations. On linux, the read call block as expected. 2 - On linux, when calling inputstream.read() in a loop, the call will block when there is no more data to collect. This is the expected behavior. However, when blocked on the read call, no more events are dispatched to the listeners. Is this normal/expected? I would like to have a thread that read data in a loop while being notified of other events (like break, output empty, ...) 3 - It seems that I can't get break events on linux. I can send break signal but the break event is never received. I have a windows laptop running the latest gnu.io rxtx version and a linux box running the latest gnu.io rxtx. The windows laptop is receiving break events but not the linux one. I should note that I am using a RS232 to RS422 adapter since my linux hardware only has a RS422 interface. Also note that the RS422 port is using a USB-Serial. 4 - The break event sent from linux is not of the specified duration. I see in the rxtx code that we divide the received duration by 250 before calling the tcsendbreak. Is there a reason? When I call sendBreak with 500000, the actual break sent in about 2000ms which match what the code does. Thank you very much! Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080502/0588fb08/attachment-0051.html From Martin.Oberhuber at windriver.com Fri May 2 11:38:02 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 2 May 2008 19:38:02 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Hi Trent, Thanks for the pointer to the FHS standard. Yet I see 11 (!) direcotries checked in RXTX lockdaemon.c / is_device_locked() Are some of these moot with modern Unix / Linux? It looks like checking for locks is easier than creating a lock in the right location, when multiple possible lock folders are there. I'm all in favor of the ioctl method here. It also automatically gets rid of stale locks on a reboot, does that also happen with Lockfiles? Steffen: I see your points from an admin / user point of view. But many of our customers use Linux boxes these days in a pure single-user mode. I'm OK if our software doesn't have permission to create locks, but the very least that it must be able to do, is (1) IF there is non-admin access to the ports configured, our software must be able to use it out of the box. (2) if it is not configured, and opening the port fails, our software mut be able to tell the user WHY accessing the serial port failed ("write permission denied on /var/lock/LCK..ttyS0") (3) In addition to that, online docs should be able to tell the user what she can do to fix the issue. Notwithstanding any access privileges that may be set for good reasons, we must expect that the user wanted to open the serial port for good reason, and we should do everything we can to help the user doing so. Even if that Includes hints how to gain the required Privileges. The absolute minimum for me is (2), exact reporting what went wrong. Just saying "Failed to create a lockfile" is not Acceptable at all. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Trent Jarvi > Sent: Mittwoch, 30. April 2008 00:12 > To: Steffen DETTMER > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] RXTX port locking on Linux status? > > > The statement `Linux systems use /var/lock' is interesting, does > > anyone know the source of this convention? > > These details are outlined in the Filesystem Hierarchy Standard (FHS). > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From zuran at pandora.be Sat May 3 01:21:52 2008 From: zuran at pandora.be (Danny) Date: Sat, 3 May 2008 09:21:52 +0200 Subject: [Rxtx] detect dll Message-ID: <391BFB36941B48B5A6A53945E256CDF3@PCvanDanny> hi, what is the best way to detect if the dll are in the class path, and put them there at start of the application ? regards zuran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080503/edc624e2/attachment-0051.html From tjarvi at qbang.org Sat May 3 08:50:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 3 May 2008 08:50:19 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: On Fri, 2 May 2008, Oberhuber, Martin wrote: > Hi Trent, > > Thanks for the pointer to the FHS standard. > > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? > Modern systems reduce the number of directories. The problem is older software that may or may not come with source code. Think of older software that creates lockfiles in the wrong place while sending an expensive fax. This may even be something 'odd' like UnixWare software purchased in the 80's running with the help of additional libraries on Linux. When we break software like that, it means someone is losing productivity/money/... These odd machines are ideal for upgrading to a solution that uses RXTX and I expect this situation does happen during transition. Even if we go with the IOCTL, we need to respect the random lockfiles before trying to open the port. -- Trent Jarvi tjarvi at qbang.org From vorobyev.a at gmail.com Mon May 5 03:57:48 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 13:57:48 +0400 Subject: [Rxtx] Latest Sources Message-ID: <481EDA1C.7090501@gmail.com> Good day How i can get latest sources from cvs repository? I have got used to use subversion, and not so well I am able to use CVS. I tried to search in many folders - everywhere for very old versions of source codes. Thanks for any help. From Martin.Oberhuber at windriver.com Mon May 5 02:29:09 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:29:09 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Thanks Trent. When I understand you right, this means that we need to check for lockfiles in a large number of folders, because there could be some (old) software using such folders. But what folder do we create the lockfile in? - Given that old Fax software uses /foo/bar/mylocks and we create our lockfile in the folder expected by FHS, that old Fax software will fail when we own the port while it wants to send a fax, right? Or would we create multiple lockfiles in multiple folders? But that sounds problematic in case the machine fails or goes for a reboot while we own the port -- admin would need to clean up lockfiles in multiple folders. At any rate, I want the lockfile mechansim customizable by the client software at runtime. Consider the case where user wants to use serial port on a machine where he doesn't have root access, and some old rogue lockfile is still residing in /foo/bar/mylocks. User wouldn't have a chance getting the issue fixed without an admin's help (which can take long to obtain), unless RXTX allows overriding the lockfile mechanism if needed. >From a user's perspective, I think it would make sense That RXTX behaves as follows when a lockfile is detected In an odd place: Show a dialog like "The serial port /dev/ttyS0 appears to be locked due to a lockfile in /foo/bar/mylocks. Do you want to override this lock, try again or cancel? [Override Once] [Override Always] [Try again] [Cancel] " Where * "Override Once" ignores the lockfile this time only (not really a very useful option IMHO, could be avoided) * "Override Always" always ignores lockfiles in this folder * "Try again" allows user to close down external applicaion and then check for lockfiles again * "Cancel" stops trying to open the port because it's apparently really owned. Of course such a dialog must come from the client software And not from RXTX. But RXTX must provide API to allow such A dialog, particularly return the folder in which the Lockfile was found along with the exception that reports Failure opening the port. And an API for specifiying a (list of) folders to ignore When searching for lockfiles. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 03. Mai 2008 16:50 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > On Fri, 2 May 2008, Oberhuber, Martin wrote: > > > Hi Trent, > > > > Thanks for the pointer to the FHS standard. > > > > Yet I see 11 (!) direcotries checked in RXTX > > lockdaemon.c / is_device_locked() > > Are some of these moot with modern Unix / Linux? > > > > Modern systems reduce the number of directories. The problem > is older > software that may or may not come with source code. Think of older > software that creates lockfiles in the wrong place while sending an > expensive fax. This may even be something 'odd' like > UnixWare software > purchased in the 80's running with the help of additional > libraries on > Linux. When we break software like that, it means someone is losing > productivity/money/... > > These odd machines are ideal for upgrading to a solution that > uses RXTX > and I expect this situation does happen during transition. > > Even if we go with the IOCTL, we need to respect the random lockfiles > before trying to open the port. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From Martin.Oberhuber at windriver.com Mon May 5 02:35:59 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 5 May 2008 10:35:59 +0200 Subject: [Rxtx] Latest Sources In-Reply-To: <481EDA1C.7090501@gmail.com> References: <481EDA1C.7090501@gmail.com> Message-ID: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Hello Alexander, A sample session is on http://users.frii.com/jarvi/rxtx/cvs.html it's only missing the fact that you need to switch to branch "commapi-0-0-1" to get the latest sources (Trent, you might want to add that on the page). CVS Repository is :pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot CVS Module is rxtx-devel CVS Branch is commapi-0-0-1 Only the branch holds newest sources. With commandline CVS, this Is what you need to do (on Linux / Bash): CVSROOT=:pserver:anonymous at cvs.milestonesolutions.com:/usr/local/cvsroot export CVSROOT cvs login login> mousy cvs co -r commapi-0-0-1 rxtx-devel If you use Ecipse, you can open the "CVS Repository" perspective and copy&paste the Repository location into it, then expand the node (enter "mousy" for password when prompted) to module rxtx-devel, then right-click > check out as > new project. Once you have the project, right-click > Team > Switch to another branch or version > and enter commapi-0-0-1 Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Alexander Vorobyev > Sent: Montag, 05. Mai 2008 11:58 > To: rxtx at qbang.org > Subject: [Rxtx] Latest Sources > > Good day > > How i can get latest sources from cvs repository? I have got > used to use > subversion, and not so well I am able to use CVS. > I tried to search in many folders - everywhere for very old > versions of > source codes. > > Thanks for any help. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Mon May 5 03:13:12 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 5 May 2008 11:13:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> Message-ID: <20080505091311.GB2928@elberon.bln.de.ingenico.com> * Oberhuber, Martin wrote on Fri, May 02, 2008 at 19:38 +0200: > Yet I see 11 (!) direcotries checked in RXTX > lockdaemon.c / is_device_locked() > Are some of these moot with modern Unix / Linux? I guess the number of is so large because rxtx supports so many unices. This is a big advantage of but also a big challenge for rxtx IMHO. Implementing some usable locking scheme for major linux distributions of lets say last five years wouldn't probably that difficult, but what is with special environments, running different versions, distributions or unices. Or one of the different windows versions. Great range that is supported by rxtx. > It looks like checking for locks is easier than > creating a lock in the right location, when > multiple possible lock folders are there. I'm > all in favor of the ioctl method here. It also > automatically gets rid of stale locks on a reboot, > does that also happen with Lockfiles? So it seems that this depends on the application but is not general? > Steffen: I see your points from an admin / user > point of view. But many of our customers use > Linux boxes these days in a pure single-user > mode. unfortunality, yes, I know. A result of those linux advertisings. But still for me it cannot be right to make single user linux software just because many use it incorrectly and expect strange behavior they are used to get from one special system by one special vendor ;-) However, I don't see a big problem here. I think, in such a setup that single user usually can be requested to install some application package with all priviledges (lets say running apt as root or alike). Such an installer could care about such system defaults. I guess, locking on linux could be distribution and version dependent. So some installer could create some /etc/application.conf. It could ask (or decide if wiser than the user :)) whether to add users to some group like uucp or whatever is needed. If only one linux is to be supported, maybe dedicated for some application, such an installer shouldn't be too difficult I think. Maybe a look to some minicom package also gives a hint. Personally, I'm used that admin must put the users allowed to access the modem to some group. I would expect a modern linux distribution to have some solution for it, such as putting the first created user to this group automatically (to allow internet modem stuff), but today sometimes it is solved very complex with some tray application telling some deamon to start some other daemon to wrap pppd... > I'm OK if our software doesn't have permission to create locks, > but the very least that it must be able to do, is > > (1) IF there is non-admin access to the > ports configured, our software must > be able to use it out of the box. I'm not sure if I understand this. If permissions are insufficient to create a proper lock file, opening the port should fail because of the same reason, shouldn't it? SuSE linux for instance has drwxrwxr-t root:uucp for /var/lock and crw-rw---- root:uucp for /dev/ttyS0. If you cannot lock because not in group uucp, the serial port cannot be opened. I'd guess (but don't know) that something like this (maybe with different group name) is common? (I've heard of some kresourcemgr that can additionally limit permissions [breaking cdrecord for root] and of course the `security hardening' features that may also be of concern.) > (2) if it is not configured, and opening > the port fails, our software mut be > able to tell the user WHY accessing > the serial port failed ("write > permission denied on /var/lock/LCK..ttyS0") Yes, I agree, of course. Messages shall be detailed, concrete and include information of higher layers also (easy in Java with exceptions and catch-extend-throwagain). Sometimes it might be suited to distinguish two detail levels of messages, summary for GUIs and end users (like your example) and details for admins/developers/support technicians (like "at , file /var/lock/LCK..ttyS0 creation with mode 644 failed with `permission denied' while trying to create a lock file for primary modem port as configured in /etc/conf, needed by the online data module when about to transmit data to the tax advisers office `Mr Mueller'."). rxtx should allow to develop such application (to the choosen logfile name and the error message must be avialable in some exception or so. Having some connection name or identifier to distinguish is helpful but not required). > (3) In addition to that, online docs should > be able to tell the user what she can do > to fix the issue. do you mean online docs of the application that uses rxtx? Then I agree. However, I would not expect to have online docs of rxtx intended for the end user (only intended for developers and documentation writers). > Notwithstanding any access privileges that may > be set for good reasons, we must expect that > the user wanted to open the serial port for > good reason, and we should do everything we > can to help the user doing so. Even if that > Includes hints how to gain the required > Privileges. here I slightly disagree. If a user has no access to serial ports (even if some lock file was created), then there is nothing rxtx should do about. What do you mean with gaining required privileges? Probably not to include a library of root exploits but maybe some password asking dialog to get root privileges? I know that some windows applications do so, but personally I really dislike that. I think installation/setup time is better suited for that (a major purpose of setup IMHO). > The absolute minimum for me is (2), exact reporting what went > wrong. Just saying "Failed to create a lockfile" is not > Acceptable at all. yeah, "ser.c:1234 ERR 0d (4,64)" or even "program aborted" are not that helpful :) For rxtx as a library, I think the requirement is to allow to write applications with proper messages, but the aborting and messaging and GUI stuff itself IMHO is out of scope of rxtx. What do you think about having the setup/installer handling permission checking/granting? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From vorobyev.a at gmail.com Mon May 5 06:21:20 2008 From: vorobyev.a at gmail.com (Alexander Vorobyev) Date: Mon, 05 May 2008 16:21:20 +0400 Subject: [Rxtx] Latest Sources In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> References: <481EDA1C.7090501@gmail.com> <460801A4097E3D4CA04CC64EE6485848058D83D6@ism-mail03.corp.ad.wrs.com> Message-ID: <481EFBC0.9090702@gmail.com> Thank you very much! From tjarvi at qbang.org Mon May 5 18:05:39 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 5 May 2008 18:05:39 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: The following has been my approach in the past. Our contract is the same as it is for other software: Do no harm. That means we should go out of our way to avoid stomping on data but it is up to other programs to avoid stepping on our data when we do the right thing. System integrators can then handle the issue. Making a symbolic link for the lock directory is a common solution. We are not obligated to create lockfiles in the wrong place or facilitate use of the incorrect location. The FHS defines this location on Linux. UUCP lockfiles are traditional Unix. With lockfiles, we do check if the program is still running. When the lockfile is there and the program is running, we may be able to provide more information but I don't think taking the port is a good option. The right solution is to exit the other program/close the serial port/.. For Linux, we even had code that told the user what the application was at one point. It may not be true anymore. In the cases that a lockfile has been left but the application is no longer running, we remove the lock without input. The lock is no longer valid. I don't think rxtx is the place to implement a 'sortof locked' mechanism. If an application wants to override the expected behavior, the author is free to do that before rxtx looks in a lock directory. It may be possible to offer preferences to not look in legacy directories but I question how much is gained. On Mon, 5 May 2008, Oberhuber, Martin wrote: > Thanks Trent. > > When I understand you right, this means that we need > to check for lockfiles in a large number of folders, > because there could be some (old) software using such > folders. > > But what folder do we create the lockfile in? - Given > that old Fax software uses /foo/bar/mylocks and we > create our lockfile in the folder expected by FHS, > that old Fax software will fail when we own the port > while it wants to send a fax, right? > > Or would we create multiple lockfiles in multiple folders? > But that sounds problematic in case the machine fails > or goes for a reboot while we own the port -- admin would > need to clean up lockfiles in multiple folders. > > At any rate, I want the lockfile mechansim customizable > by the client software at runtime. Consider the case > where user wants to use serial port on a machine where > he doesn't have root access, and some old rogue lockfile > is still residing in /foo/bar/mylocks. User wouldn't > have a chance getting the issue fixed without an admin's > help (which can take long to obtain), unless RXTX allows > overriding the lockfile mechanism if needed. > >> From a user's perspective, I think it would make sense > That RXTX behaves as follows when a lockfile is detected > In an odd place: Show a dialog like > > "The serial port /dev/ttyS0 appears to be locked due > to a lockfile in /foo/bar/mylocks. Do you want to > override this lock, try again or cancel? > > [Override Once] [Override Always] [Try again] [Cancel] > " > > Where > * "Override Once" ignores the lockfile this time only > (not really a very useful option IMHO, could be avoided) > * "Override Always" always ignores lockfiles in this folder > * "Try again" allows user to close down external applicaion > and then check for lockfiles again > * "Cancel" stops trying to open the port because it's > apparently really owned. > > Of course such a dialog must come from the client software > And not from RXTX. But RXTX must provide API to allow such > A dialog, particularly return the folder in which the > Lockfile was found along with the exception that reports > Failure opening the port. > > And an API for specifiying a (list of) folders to ignore > When searching for lockfiles. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Samstag, 03. Mai 2008 16:50 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> On Fri, 2 May 2008, Oberhuber, Martin wrote: >> >>> Hi Trent, >>> >>> Thanks for the pointer to the FHS standard. >>> >>> Yet I see 11 (!) direcotries checked in RXTX >>> lockdaemon.c / is_device_locked() >>> Are some of these moot with modern Unix / Linux? >>> >> >> Modern systems reduce the number of directories. The problem >> is older >> software that may or may not come with source code. Think of older >> software that creates lockfiles in the wrong place while sending an >> expensive fax. This may even be something 'odd' like >> UnixWare software >> purchased in the 80's running with the help of additional >> libraries on >> Linux. When we break software like that, it means someone is losing >> productivity/money/... >> >> These odd machines are ideal for upgrading to a solution that >> uses RXTX >> and I expect this situation does happen during transition. >> >> Even if we go with the IOCTL, we need to respect the random lockfiles >> before trying to open the port. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > From 200302251 at uaeu.ac.ae Tue May 6 07:15:44 2008 From: 200302251 at uaeu.ac.ae (200302251 at uaeu.ac.ae) Date: Tue, 06 May 2008 17:15:44 +0400 Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080506/3596bd27/attachment-0047.html From tjarvi at qbang.org Tue May 6 19:36:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 6 May 2008 19:36:32 -0600 (MDT) Subject: [Rxtx] Q about the error of at gnu.io.RXTXPort.nativeDrain(Native Method)...... In-Reply-To: References: Message-ID: On Tue, 6 May 2008, 200302251 at uaeu.ac.ae wrote: > > Hello, > > I am Miss.M, a member of group worked in UAEU. > I want to ask? if you have any idea of this kinds of errors, I did a lot > of searches without good & clear results. > > So, We are group working in project with the Robotic arm(R17), we build > now a small program(with Java) successfuly that interact with the Robotic > arm by establish a connection using the USB port using RXTX package since > its work with Windows(We found that the package of comm didn't do that!). > We give orders(Some commands to run with) to the Robotic to move it after > we establish the connection. > Until now, the Robotic arm receive these commands and?run?them to move. > Although when compiling the program and?when send?every command to the > Robotic, it shows us an error msg but it works fine! we have to fix this > bug or problem because sometimes the window and the system shutdown > suddenly! > > The same exception appears again and again in each step, > although it seems that the operation is succesful, i.e. exception is > thrown but the data gets read correctly!!! > > > here is the error: > > > > at gnu.io.RXTXPort.nativeDrain(Native Method) > > at gnu.io.RXTXPort$SerialOutputStream.flush(RXTXPort.java:1201) > > Can you help us please & suggest some sulotions?? > I've seen this with some USB bluetooth devices. The solution (workaround) was to ignore the error. This is probably a bug in the vendors driver. RXTX tries to determine the capabilities of the driver and if it is not very smart, rxtx uses flush/tcdrain to determine if the output buffer is empty. Some drivers do not handle the flush well. Perhaps for valid reasons from the hardware perspective (how the heck should I know if the data is written?) I suspect RXTX triggers errors like this more commonly than other software. It is almost for sure a problem with the driver though. If you don't care, don't pay attention to the error. Try and catch it. Or even better, report it to the vendor. I usually don't know what device/vendor is being reported about. But if you get the info, let the vendor know. Perhaps I'm missing something and there is a problem in rxtx. Vendors may see this email. I've even had exchanges with what turned out to be a driver writer. But the working hypothesis has not been wrong yet. Upgrading drivers has resolved the situation for some people. -- Trent Jarvi tjarvi at qbang.org From Martin.Oberhuber at windriver.com Fri May 9 03:02:38 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:02:38 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Thanks Trent, This approach sounds very good and useful. The only thing that I ask is that in case RXTX is Not able to take a port for any reason (i.e. open() Fails), the exception thrown must be verbose enough For a user (or automated programmatic client) to Diagnose the problem and suggest proper steps. In other words, if a valid lockfile is found, The exception must report the exact path of the Lockfile. If the ioctl method is used and it fails for a port (although no lockfile had been found), the exception Must report that the ioctl failed. Makes sense? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Dienstag, 06. Mai 2008 02:06 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > The following has been my approach in the past. > > Our contract is the same as it is for other software: Do no harm. > > That means we should go out of our way to avoid stomping on > data but it is > up to other programs to avoid stepping on our data when we do > the right > thing. System integrators can then handle the issue. Making > a symbolic > link for the lock directory is a common solution. > > We are not obligated to create lockfiles in the wrong place > or facilitate > use of the incorrect location. The FHS defines this location > on Linux. > UUCP lockfiles are traditional Unix. > > With lockfiles, we do check if the program is still running. > When the > lockfile is there and the program is running, we may be able > to provide > more information but I don't think taking the port is a good > option. The > right solution is to exit the other program/close the serial > port/.. For > Linux, we even had code that told the user what the > application was at one > point. It may not be true anymore. > > In the cases that a lockfile has been left but the application is no > longer running, we remove the lock without input. The lock > is no longer > valid. > > I don't think rxtx is the place to implement a 'sortof > locked' mechanism. > If an application wants to override the expected behavior, > the author is > free to do that before rxtx looks in a lock directory. It > may be possible > to offer preferences to not look in legacy directories but I > question how > much is gained. > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > Thanks Trent. > > > > When I understand you right, this means that we need > > to check for lockfiles in a large number of folders, > > because there could be some (old) software using such > > folders. > > > > But what folder do we create the lockfile in? - Given > > that old Fax software uses /foo/bar/mylocks and we > > create our lockfile in the folder expected by FHS, > > that old Fax software will fail when we own the port > > while it wants to send a fax, right? > > > > Or would we create multiple lockfiles in multiple folders? > > But that sounds problematic in case the machine fails > > or goes for a reboot while we own the port -- admin would > > need to clean up lockfiles in multiple folders. > > > > At any rate, I want the lockfile mechansim customizable > > by the client software at runtime. Consider the case > > where user wants to use serial port on a machine where > > he doesn't have root access, and some old rogue lockfile > > is still residing in /foo/bar/mylocks. User wouldn't > > have a chance getting the issue fixed without an admin's > > help (which can take long to obtain), unless RXTX allows > > overriding the lockfile mechanism if needed. > > > >> From a user's perspective, I think it would make sense > > That RXTX behaves as follows when a lockfile is detected > > In an odd place: Show a dialog like > > > > "The serial port /dev/ttyS0 appears to be locked due > > to a lockfile in /foo/bar/mylocks. Do you want to > > override this lock, try again or cancel? > > > > [Override Once] [Override Always] [Try again] [Cancel] > > " > > > > Where > > * "Override Once" ignores the lockfile this time only > > (not really a very useful option IMHO, could be avoided) > > * "Override Always" always ignores lockfiles in this folder > > * "Try again" allows user to close down external applicaion > > and then check for lockfiles again > > * "Cancel" stops trying to open the port because it's > > apparently really owned. > > > > Of course such a dialog must come from the client software > > And not from RXTX. But RXTX must provide API to allow such > > A dialog, particularly return the folder in which the > > Lockfile was found along with the exception that reports > > Failure opening the port. > > > > And an API for specifiying a (list of) folders to ignore > > When searching for lockfiles. > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >> Sent: Samstag, 03. Mai 2008 16:50 > >> To: Oberhuber, Martin > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >> > >>> Hi Trent, > >>> > >>> Thanks for the pointer to the FHS standard. > >>> > >>> Yet I see 11 (!) direcotries checked in RXTX > >>> lockdaemon.c / is_device_locked() > >>> Are some of these moot with modern Unix / Linux? > >>> > >> > >> Modern systems reduce the number of directories. The problem > >> is older > >> software that may or may not come with source code. Think of older > >> software that creates lockfiles in the wrong place while sending an > >> expensive fax. This may even be something 'odd' like > >> UnixWare software > >> purchased in the 80's running with the help of additional > >> libraries on > >> Linux. When we break software like that, it means someone > is losing > >> productivity/money/... > >> > >> These odd machines are ideal for upgrading to a solution that > >> uses RXTX > >> and I expect this situation does happen during transition. > >> > >> Even if we go with the IOCTL, we need to respect the > random lockfiles > >> before trying to open the port. > >> > >> -- > >> Trent Jarvi > >> tjarvi at qbang.org > >> > >> > >> > > > From Martin.Oberhuber at windriver.com Fri May 9 03:05:12 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 9 May 2008 11:05:12 +0200 Subject: [Rxtx] RXTX port locking on Linux status? References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> PS The other request I have is that the client software Can configure additional port locking directory/ies For both lockfile checking and lcokfile creation. Just like minicom or others allow commandline option To overrdie the lockfile directory (or even switch Off lockfile checking completely, if a user wants that). Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Freitag, 09. Mai 2008 11:03 > To: 'Trent Jarvi' > Cc: Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Trent Jarvi [mailto:tjarvi at qbang.org] > > Sent: Dienstag, 06. Mai 2008 02:06 > > To: Oberhuber, Martin > > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > > > > The following has been my approach in the past. > > > > Our contract is the same as it is for other software: Do no harm. > > > > That means we should go out of our way to avoid stomping on > > data but it is > > up to other programs to avoid stepping on our data when we do > > the right > > thing. System integrators can then handle the issue. Making > > a symbolic > > link for the lock directory is a common solution. > > > > We are not obligated to create lockfiles in the wrong place > > or facilitate > > use of the incorrect location. The FHS defines this location > > on Linux. > > UUCP lockfiles are traditional Unix. > > > > With lockfiles, we do check if the program is still running. > > When the > > lockfile is there and the program is running, we may be able > > to provide > > more information but I don't think taking the port is a good > > option. The > > right solution is to exit the other program/close the serial > > port/.. For > > Linux, we even had code that told the user what the > > application was at one > > point. It may not be true anymore. > > > > In the cases that a lockfile has been left but the > application is no > > longer running, we remove the lock without input. The lock > > is no longer > > valid. > > > > I don't think rxtx is the place to implement a 'sortof > > locked' mechanism. > > If an application wants to override the expected behavior, > > the author is > > free to do that before rxtx looks in a lock directory. It > > may be possible > > to offer preferences to not look in legacy directories but I > > question how > > much is gained. > > > > On Mon, 5 May 2008, Oberhuber, Martin wrote: > > > > > Thanks Trent. > > > > > > When I understand you right, this means that we need > > > to check for lockfiles in a large number of folders, > > > because there could be some (old) software using such > > > folders. > > > > > > But what folder do we create the lockfile in? - Given > > > that old Fax software uses /foo/bar/mylocks and we > > > create our lockfile in the folder expected by FHS, > > > that old Fax software will fail when we own the port > > > while it wants to send a fax, right? > > > > > > Or would we create multiple lockfiles in multiple folders? > > > But that sounds problematic in case the machine fails > > > or goes for a reboot while we own the port -- admin would > > > need to clean up lockfiles in multiple folders. > > > > > > At any rate, I want the lockfile mechansim customizable > > > by the client software at runtime. Consider the case > > > where user wants to use serial port on a machine where > > > he doesn't have root access, and some old rogue lockfile > > > is still residing in /foo/bar/mylocks. User wouldn't > > > have a chance getting the issue fixed without an admin's > > > help (which can take long to obtain), unless RXTX allows > > > overriding the lockfile mechanism if needed. > > > > > >> From a user's perspective, I think it would make sense > > > That RXTX behaves as follows when a lockfile is detected > > > In an odd place: Show a dialog like > > > > > > "The serial port /dev/ttyS0 appears to be locked due > > > to a lockfile in /foo/bar/mylocks. Do you want to > > > override this lock, try again or cancel? > > > > > > [Override Once] [Override Always] [Try again] [Cancel] > > > " > > > > > > Where > > > * "Override Once" ignores the lockfile this time only > > > (not really a very useful option IMHO, could be avoided) > > > * "Override Always" always ignores lockfiles in this folder > > > * "Try again" allows user to close down external applicaion > > > and then check for lockfiles again > > > * "Cancel" stops trying to open the port because it's > > > apparently really owned. > > > > > > Of course such a dialog must come from the client software > > > And not from RXTX. But RXTX must provide API to allow such > > > A dialog, particularly return the folder in which the > > > Lockfile was found along with the exception that reports > > > Failure opening the port. > > > > > > And an API for specifiying a (list of) folders to ignore > > > When searching for lockfiles. > > > > > > Cheers, > > > -- > > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > > Target Management Project Lead, DSDP PMC Member > > > http://www.eclipse.org/dsdp/tm > > > > > > > > > > > >> -----Original Message----- > > >> From: Trent Jarvi [mailto:tjarvi at qbang.org] > > >> Sent: Samstag, 03. Mai 2008 16:50 > > >> To: Oberhuber, Martin > > >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > > >> > > >> On Fri, 2 May 2008, Oberhuber, Martin wrote: > > >> > > >>> Hi Trent, > > >>> > > >>> Thanks for the pointer to the FHS standard. > > >>> > > >>> Yet I see 11 (!) direcotries checked in RXTX > > >>> lockdaemon.c / is_device_locked() > > >>> Are some of these moot with modern Unix / Linux? > > >>> > > >> > > >> Modern systems reduce the number of directories. The problem > > >> is older > > >> software that may or may not come with source code. > Think of older > > >> software that creates lockfiles in the wrong place while > sending an > > >> expensive fax. This may even be something 'odd' like > > >> UnixWare software > > >> purchased in the 80's running with the help of additional > > >> libraries on > > >> Linux. When we break software like that, it means someone > > is losing > > >> productivity/money/... > > >> > > >> These odd machines are ideal for upgrading to a solution that > > >> uses RXTX > > >> and I expect this situation does happen during transition. > > >> > > >> Even if we go with the IOCTL, we need to respect the > > random lockfiles > > >> before trying to open the port. > > >> > > >> -- > > >> Trent Jarvi > > >> tjarvi at qbang.org > > >> > > >> > > >> > > > > > From lyon at docjava.com Fri May 9 03:38:32 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 09 May 2008 05:38:32 -0400 Subject: [Rxtx] USB->Parallel Port in java In-Reply-To: References: Message-ID: Has anyone tried using rxtx to program the USB to parallel port dongles? Thanks! - Doug From tjarvi at qbang.org Fri May 9 19:07:06 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:07:06 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A75668@ism-mail03.corp.ad.wrs.com> Message-ID: This makes sense to me. On Fri, 9 May 2008, Oberhuber, Martin wrote: > Thanks Trent, > > This approach sounds very good and useful. > > The only thing that I ask is that in case RXTX is > Not able to take a port for any reason (i.e. open() > Fails), the exception thrown must be verbose enough > For a user (or automated programmatic client) to > Diagnose the problem and suggest proper steps. > > In other words, if a valid lockfile is found, > The exception must report the exact path of the > Lockfile. > > If the ioctl method is used and it fails for a port > (although no lockfile had been found), the exception > Must report that the ioctl failed. > > Makes sense? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Trent Jarvi [mailto:tjarvi at qbang.org] >> Sent: Dienstag, 06. Mai 2008 02:06 >> To: Oberhuber, Martin >> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> >> The following has been my approach in the past. >> >> Our contract is the same as it is for other software: Do no harm. >> >> That means we should go out of our way to avoid stomping on >> data but it is >> up to other programs to avoid stepping on our data when we do >> the right >> thing. System integrators can then handle the issue. Making >> a symbolic >> link for the lock directory is a common solution. >> >> We are not obligated to create lockfiles in the wrong place >> or facilitate >> use of the incorrect location. The FHS defines this location >> on Linux. >> UUCP lockfiles are traditional Unix. >> >> With lockfiles, we do check if the program is still running. >> When the >> lockfile is there and the program is running, we may be able >> to provide >> more information but I don't think taking the port is a good >> option. The >> right solution is to exit the other program/close the serial >> port/.. For >> Linux, we even had code that told the user what the >> application was at one >> point. It may not be true anymore. >> >> In the cases that a lockfile has been left but the application is no >> longer running, we remove the lock without input. The lock >> is no longer >> valid. >> >> I don't think rxtx is the place to implement a 'sortof >> locked' mechanism. >> If an application wants to override the expected behavior, >> the author is >> free to do that before rxtx looks in a lock directory. It >> may be possible >> to offer preferences to not look in legacy directories but I >> question how >> much is gained. >> >> On Mon, 5 May 2008, Oberhuber, Martin wrote: >> >>> Thanks Trent. >>> >>> When I understand you right, this means that we need >>> to check for lockfiles in a large number of folders, >>> because there could be some (old) software using such >>> folders. >>> >>> But what folder do we create the lockfile in? - Given >>> that old Fax software uses /foo/bar/mylocks and we >>> create our lockfile in the folder expected by FHS, >>> that old Fax software will fail when we own the port >>> while it wants to send a fax, right? >>> >>> Or would we create multiple lockfiles in multiple folders? >>> But that sounds problematic in case the machine fails >>> or goes for a reboot while we own the port -- admin would >>> need to clean up lockfiles in multiple folders. >>> >>> At any rate, I want the lockfile mechansim customizable >>> by the client software at runtime. Consider the case >>> where user wants to use serial port on a machine where >>> he doesn't have root access, and some old rogue lockfile >>> is still residing in /foo/bar/mylocks. User wouldn't >>> have a chance getting the issue fixed without an admin's >>> help (which can take long to obtain), unless RXTX allows >>> overriding the lockfile mechanism if needed. >>> >>>> From a user's perspective, I think it would make sense >>> That RXTX behaves as follows when a lockfile is detected >>> In an odd place: Show a dialog like >>> >>> "The serial port /dev/ttyS0 appears to be locked due >>> to a lockfile in /foo/bar/mylocks. Do you want to >>> override this lock, try again or cancel? >>> >>> [Override Once] [Override Always] [Try again] [Cancel] >>> " >>> >>> Where >>> * "Override Once" ignores the lockfile this time only >>> (not really a very useful option IMHO, could be avoided) >>> * "Override Always" always ignores lockfiles in this folder >>> * "Try again" allows user to close down external applicaion >>> and then check for lockfiles again >>> * "Cancel" stops trying to open the port because it's >>> apparently really owned. >>> >>> Of course such a dialog must come from the client software >>> And not from RXTX. But RXTX must provide API to allow such >>> A dialog, particularly return the folder in which the >>> Lockfile was found along with the exception that reports >>> Failure opening the port. >>> >>> And an API for specifiying a (list of) folders to ignore >>> When searching for lockfiles. >>> >>> Cheers, >>> -- >>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>> Target Management Project Lead, DSDP PMC Member >>> http://www.eclipse.org/dsdp/tm >>> >>> >>> >>>> -----Original Message----- >>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>> Sent: Samstag, 03. Mai 2008 16:50 >>>> To: Oberhuber, Martin >>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>> >>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>> >>>>> Hi Trent, >>>>> >>>>> Thanks for the pointer to the FHS standard. >>>>> >>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>> lockdaemon.c / is_device_locked() >>>>> Are some of these moot with modern Unix / Linux? >>>>> >>>> >>>> Modern systems reduce the number of directories. The problem >>>> is older >>>> software that may or may not come with source code. Think of older >>>> software that creates lockfiles in the wrong place while sending an >>>> expensive fax. This may even be something 'odd' like >>>> UnixWare software >>>> purchased in the 80's running with the help of additional >>>> libraries on >>>> Linux. When we break software like that, it means someone >> is losing >>>> productivity/money/... >>>> >>>> These odd machines are ideal for upgrading to a solution that >>>> uses RXTX >>>> and I expect this situation does happen during transition. >>>> >>>> Even if we go with the IOCTL, we need to respect the >> random lockfiles >>>> before trying to open the port. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> >>> >> > From tjarvi at qbang.org Fri May 9 19:13:25 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 9 May 2008 19:13:25 -0600 (MDT) Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: It would probably make more sense to just do an exclusive open than start creating lockfiles in other places. On Fri, 9 May 2008, Oberhuber, Martin wrote: > PS > > The other request I have is that the client software > Can configure additional port locking directory/ies > For both lockfile checking and lcokfile creation. > > Just like minicom or others allow commandline option > To overrdie the lockfile directory (or even switch > Off lockfile checking completely, if a user wants that). > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: Oberhuber, Martin >> Sent: Freitag, 09. Mai 2008 11:03 >> To: 'Trent Jarvi' >> Cc: Steffen DETTMER; rxtx at qbang.org >> Subject: RE: [Rxtx] RXTX port locking on Linux status? >> >> Thanks Trent, >> >> This approach sounds very good and useful. >> >> The only thing that I ask is that in case RXTX is >> Not able to take a port for any reason (i.e. open() >> Fails), the exception thrown must be verbose enough >> For a user (or automated programmatic client) to >> Diagnose the problem and suggest proper steps. >> >> In other words, if a valid lockfile is found, >> The exception must report the exact path of the >> Lockfile. >> >> If the ioctl method is used and it fails for a port >> (although no lockfile had been found), the exception >> Must report that the ioctl failed. >> >> Makes sense? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>> Sent: Dienstag, 06. Mai 2008 02:06 >>> To: Oberhuber, Martin >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>> >>> >>> The following has been my approach in the past. >>> >>> Our contract is the same as it is for other software: Do no harm. >>> >>> That means we should go out of our way to avoid stomping on >>> data but it is >>> up to other programs to avoid stepping on our data when we do >>> the right >>> thing. System integrators can then handle the issue. Making >>> a symbolic >>> link for the lock directory is a common solution. >>> >>> We are not obligated to create lockfiles in the wrong place >>> or facilitate >>> use of the incorrect location. The FHS defines this location >>> on Linux. >>> UUCP lockfiles are traditional Unix. >>> >>> With lockfiles, we do check if the program is still running. >>> When the >>> lockfile is there and the program is running, we may be able >>> to provide >>> more information but I don't think taking the port is a good >>> option. The >>> right solution is to exit the other program/close the serial >>> port/.. For >>> Linux, we even had code that told the user what the >>> application was at one >>> point. It may not be true anymore. >>> >>> In the cases that a lockfile has been left but the >> application is no >>> longer running, we remove the lock without input. The lock >>> is no longer >>> valid. >>> >>> I don't think rxtx is the place to implement a 'sortof >>> locked' mechanism. >>> If an application wants to override the expected behavior, >>> the author is >>> free to do that before rxtx looks in a lock directory. It >>> may be possible >>> to offer preferences to not look in legacy directories but I >>> question how >>> much is gained. >>> >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: >>> >>>> Thanks Trent. >>>> >>>> When I understand you right, this means that we need >>>> to check for lockfiles in a large number of folders, >>>> because there could be some (old) software using such >>>> folders. >>>> >>>> But what folder do we create the lockfile in? - Given >>>> that old Fax software uses /foo/bar/mylocks and we >>>> create our lockfile in the folder expected by FHS, >>>> that old Fax software will fail when we own the port >>>> while it wants to send a fax, right? >>>> >>>> Or would we create multiple lockfiles in multiple folders? >>>> But that sounds problematic in case the machine fails >>>> or goes for a reboot while we own the port -- admin would >>>> need to clean up lockfiles in multiple folders. >>>> >>>> At any rate, I want the lockfile mechansim customizable >>>> by the client software at runtime. Consider the case >>>> where user wants to use serial port on a machine where >>>> he doesn't have root access, and some old rogue lockfile >>>> is still residing in /foo/bar/mylocks. User wouldn't >>>> have a chance getting the issue fixed without an admin's >>>> help (which can take long to obtain), unless RXTX allows >>>> overriding the lockfile mechanism if needed. >>>> >>>>> From a user's perspective, I think it would make sense >>>> That RXTX behaves as follows when a lockfile is detected >>>> In an odd place: Show a dialog like >>>> >>>> "The serial port /dev/ttyS0 appears to be locked due >>>> to a lockfile in /foo/bar/mylocks. Do you want to >>>> override this lock, try again or cancel? >>>> >>>> [Override Once] [Override Always] [Try again] [Cancel] >>>> " >>>> >>>> Where >>>> * "Override Once" ignores the lockfile this time only >>>> (not really a very useful option IMHO, could be avoided) >>>> * "Override Always" always ignores lockfiles in this folder >>>> * "Try again" allows user to close down external applicaion >>>> and then check for lockfiles again >>>> * "Cancel" stops trying to open the port because it's >>>> apparently really owned. >>>> >>>> Of course such a dialog must come from the client software >>>> And not from RXTX. But RXTX must provide API to allow such >>>> A dialog, particularly return the folder in which the >>>> Lockfile was found along with the exception that reports >>>> Failure opening the port. >>>> >>>> And an API for specifiying a (list of) folders to ignore >>>> When searching for lockfiles. >>>> >>>> Cheers, >>>> -- >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River >>>> Target Management Project Lead, DSDP PMC Member >>>> http://www.eclipse.org/dsdp/tm >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] >>>>> Sent: Samstag, 03. Mai 2008 16:50 >>>>> To: Oberhuber, Martin >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? >>>>> >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: >>>>> >>>>>> Hi Trent, >>>>>> >>>>>> Thanks for the pointer to the FHS standard. >>>>>> >>>>>> Yet I see 11 (!) direcotries checked in RXTX >>>>>> lockdaemon.c / is_device_locked() >>>>>> Are some of these moot with modern Unix / Linux? >>>>>> >>>>> >>>>> Modern systems reduce the number of directories. The problem >>>>> is older >>>>> software that may or may not come with source code. >> Think of older >>>>> software that creates lockfiles in the wrong place while >> sending an >>>>> expensive fax. This may even be something 'odd' like >>>>> UnixWare software >>>>> purchased in the 80's running with the help of additional >>>>> libraries on >>>>> Linux. When we break software like that, it means someone >>> is losing >>>>> productivity/money/... >>>>> >>>>> These odd machines are ideal for upgrading to a solution that >>>>> uses RXTX >>>>> and I expect this situation does happen during transition. >>>>> >>>>> Even if we go with the IOCTL, we need to respect the >>> random lockfiles >>>>> before trying to open the port. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> >>>>> >>>>> >>>> >>> > From lyon at docjava.com Sat May 10 05:53:55 2008 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 10 May 2008 07:53:55 -0400 Subject: [Rxtx] native available - the pop-up usb error Message-ID: Hi All, Here is an interesting error: java.io.IOException: Device not configured in nativeavailable at gnu.io.RXTXPort.nativeavailable(Native Method) at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) at java.io.FilterInputStream.available(FilterInputStream.java:146) In Java, we see: protected native int nativeavailable() throws IOException; Restart of the application solves the problem. The keyspan rs232-usb device goes to a powered hub....which lost power. The keyspan device thus goes off-line and then back on-line. The mac is a lap-top (with batteries that work OK). Perhaps we can call this the Pop-Up usb error (since the device is essentially hot-plugged). I suspect that this is the case of a device that disappears and then re-appears. RXTX is probably not robust in the face of changes like this. And to make it robust might require lots of effort and thought. Is this a hard problem to address? Thanks! - Doug From Martin.Oberhuber at windriver.com Sat May 10 10:15:32 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Sat, 10 May 2008 18:15:32 +0200 Subject: [Rxtx] RXTX port locking on Linux status? In-Reply-To: References: <460801A4097E3D4CA04CC64EE6485848056CDF5B@ism-mail03.corp.ad.wrs.com><460801A4097E3D4CA04CC64EE64858480577CE32@ism-mail03.corp.ad.wrs.com><200804281928.34454.scldad@sdc.com.au><460801A4097E3D4CA04CC64EE64858480584484C@ism-mail03.corp.ad.wrs.com><20080429193444.GU2928@elberon.bln.de.ingenico.com> <460801A4097E3D4CA04CC64EE6485848058D814B@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE6485848058D83C7@ism-mail03.corp.ad.wrs.com> <460801A4097E3D4CA04CC64EE648584805A7566B@ism-mail03.corp.ad.wrs.com> Message-ID: <460801A4097E3D4CA04CC64EE648584805A758DB@ism-mail03.corp.ad.wrs.com> The point here is that if the client who uses RXTX KNOWS that on his particular system lockfiles Are used and are in position X, then RXTX should Be able to make use of that information rather Than relying on an internal series of fallbacks. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Trent Jarvi [mailto:tjarvi at qbang.org] > Sent: Samstag, 10. Mai 2008 03:13 > To: Oberhuber, Martin > Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > Subject: RE: [Rxtx] RXTX port locking on Linux status? > > > It would probably make more sense to just do an exclusive > open than start > creating lockfiles in other places. > > On Fri, 9 May 2008, Oberhuber, Martin wrote: > > > PS > > > > The other request I have is that the client software > > Can configure additional port locking directory/ies > > For both lockfile checking and lcokfile creation. > > > > Just like minicom or others allow commandline option > > To overrdie the lockfile directory (or even switch > > Off lockfile checking completely, if a user wants that). > > > > Cheers, > > -- > > Martin Oberhuber, Senior Member of Technical Staff, Wind River > > Target Management Project Lead, DSDP PMC Member > > http://www.eclipse.org/dsdp/tm > > > > > > > >> -----Original Message----- > >> From: Oberhuber, Martin > >> Sent: Freitag, 09. Mai 2008 11:03 > >> To: 'Trent Jarvi' > >> Cc: Steffen DETTMER; rxtx at qbang.org > >> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >> > >> Thanks Trent, > >> > >> This approach sounds very good and useful. > >> > >> The only thing that I ask is that in case RXTX is > >> Not able to take a port for any reason (i.e. open() > >> Fails), the exception thrown must be verbose enough > >> For a user (or automated programmatic client) to > >> Diagnose the problem and suggest proper steps. > >> > >> In other words, if a valid lockfile is found, > >> The exception must report the exact path of the > >> Lockfile. > >> > >> If the ioctl method is used and it fails for a port > >> (although no lockfile had been found), the exception > >> Must report that the ioctl failed. > >> > >> Makes sense? > >> > >> Cheers, > >> -- > >> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >> Target Management Project Lead, DSDP PMC Member > >> http://www.eclipse.org/dsdp/tm > >> > >> > >> > >>> -----Original Message----- > >>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>> Sent: Dienstag, 06. Mai 2008 02:06 > >>> To: Oberhuber, Martin > >>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>> > >>> > >>> The following has been my approach in the past. > >>> > >>> Our contract is the same as it is for other software: Do no harm. > >>> > >>> That means we should go out of our way to avoid stomping on > >>> data but it is > >>> up to other programs to avoid stepping on our data when we do > >>> the right > >>> thing. System integrators can then handle the issue. Making > >>> a symbolic > >>> link for the lock directory is a common solution. > >>> > >>> We are not obligated to create lockfiles in the wrong place > >>> or facilitate > >>> use of the incorrect location. The FHS defines this location > >>> on Linux. > >>> UUCP lockfiles are traditional Unix. > >>> > >>> With lockfiles, we do check if the program is still running. > >>> When the > >>> lockfile is there and the program is running, we may be able > >>> to provide > >>> more information but I don't think taking the port is a good > >>> option. The > >>> right solution is to exit the other program/close the serial > >>> port/.. For > >>> Linux, we even had code that told the user what the > >>> application was at one > >>> point. It may not be true anymore. > >>> > >>> In the cases that a lockfile has been left but the > >> application is no > >>> longer running, we remove the lock without input. The lock > >>> is no longer > >>> valid. > >>> > >>> I don't think rxtx is the place to implement a 'sortof > >>> locked' mechanism. > >>> If an application wants to override the expected behavior, > >>> the author is > >>> free to do that before rxtx looks in a lock directory. It > >>> may be possible > >>> to offer preferences to not look in legacy directories but I > >>> question how > >>> much is gained. > >>> > >>> On Mon, 5 May 2008, Oberhuber, Martin wrote: > >>> > >>>> Thanks Trent. > >>>> > >>>> When I understand you right, this means that we need > >>>> to check for lockfiles in a large number of folders, > >>>> because there could be some (old) software using such > >>>> folders. > >>>> > >>>> But what folder do we create the lockfile in? - Given > >>>> that old Fax software uses /foo/bar/mylocks and we > >>>> create our lockfile in the folder expected by FHS, > >>>> that old Fax software will fail when we own the port > >>>> while it wants to send a fax, right? > >>>> > >>>> Or would we create multiple lockfiles in multiple folders? > >>>> But that sounds problematic in case the machine fails > >>>> or goes for a reboot while we own the port -- admin would > >>>> need to clean up lockfiles in multiple folders. > >>>> > >>>> At any rate, I want the lockfile mechansim customizable > >>>> by the client software at runtime. Consider the case > >>>> where user wants to use serial port on a machine where > >>>> he doesn't have root access, and some old rogue lockfile > >>>> is still residing in /foo/bar/mylocks. User wouldn't > >>>> have a chance getting the issue fixed without an admin's > >>>> help (which can take long to obtain), unless RXTX allows > >>>> overriding the lockfile mechanism if needed. > >>>> > >>>>> From a user's perspective, I think it would make sense > >>>> That RXTX behaves as follows when a lockfile is detected > >>>> In an odd place: Show a dialog like > >>>> > >>>> "The serial port /dev/ttyS0 appears to be locked due > >>>> to a lockfile in /foo/bar/mylocks. Do you want to > >>>> override this lock, try again or cancel? > >>>> > >>>> [Override Once] [Override Always] [Try again] [Cancel] > >>>> " > >>>> > >>>> Where > >>>> * "Override Once" ignores the lockfile this time only > >>>> (not really a very useful option IMHO, could be avoided) > >>>> * "Override Always" always ignores lockfiles in this folder > >>>> * "Try again" allows user to close down external applicaion > >>>> and then check for lockfiles again > >>>> * "Cancel" stops trying to open the port because it's > >>>> apparently really owned. > >>>> > >>>> Of course such a dialog must come from the client software > >>>> And not from RXTX. But RXTX must provide API to allow such > >>>> A dialog, particularly return the folder in which the > >>>> Lockfile was found along with the exception that reports > >>>> Failure opening the port. > >>>> > >>>> And an API for specifiying a (list of) folders to ignore > >>>> When searching for lockfiles. > >>>> > >>>> Cheers, > >>>> -- > >>>> Martin Oberhuber, Senior Member of Technical Staff, Wind River > >>>> Target Management Project Lead, DSDP PMC Member > >>>> http://www.eclipse.org/dsdp/tm > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Trent Jarvi [mailto:tjarvi at qbang.org] > >>>>> Sent: Samstag, 03. Mai 2008 16:50 > >>>>> To: Oberhuber, Martin > >>>>> Cc: Trent Jarvi; Steffen DETTMER; rxtx at qbang.org > >>>>> Subject: RE: [Rxtx] RXTX port locking on Linux status? > >>>>> > >>>>> On Fri, 2 May 2008, Oberhuber, Martin wrote: > >>>>> > >>>>>> Hi Trent, > >>>>>> > >>>>>> Thanks for the pointer to the FHS standard. > >>>>>> > >>>>>> Yet I see 11 (!) direcotries checked in RXTX > >>>>>> lockdaemon.c / is_device_locked() > >>>>>> Are some of these moot with modern Unix / Linux? > >>>>>> > >>>>> > >>>>> Modern systems reduce the number of directories. The problem > >>>>> is older > >>>>> software that may or may not come with source code. > >> Think of older > >>>>> software that creates lockfiles in the wrong place while > >> sending an > >>>>> expensive fax. This may even be something 'odd' like > >>>>> UnixWare software > >>>>> purchased in the 80's running with the help of additional > >>>>> libraries on > >>>>> Linux. When we break software like that, it means someone > >>> is losing > >>>>> productivity/money/... > >>>>> > >>>>> These odd machines are ideal for upgrading to a solution that > >>>>> uses RXTX > >>>>> and I expect this situation does happen during transition. > >>>>> > >>>>> Even if we go with the IOCTL, we need to respect the > >>> random lockfiles > >>>>> before trying to open the port. > >>>>> > >>>>> -- > >>>>> Trent Jarvi > >>>>> tjarvi at qbang.org > >>>>> > >>>>> > >>>>> > >>>> > >>> > > > From tyleranderson5 at yahoo.com Sat May 10 14:44:56 2008 From: tyleranderson5 at yahoo.com (Tyler Anderson) Date: Sat, 10 May 2008 13:44:56 -0700 (PDT) Subject: [Rxtx] windows 64 bit support Message-ID: <549303.86192.qm@web54606.mail.re2.yahoo.com> I know this has been asked about in the past. I'm considering using rxtx for an applet, and am wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in the foreseeable future. Cheers, T From tjarvi at qbang.org Sat May 10 16:38:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:38:02 -0600 (MDT) Subject: [Rxtx] native available - the pop-up usb error In-Reply-To: References: Message-ID: On Sat, 10 May 2008, Dr. Douglas Lyon wrote: > Hi All, > Here is an interesting error: > java.io.IOException: Device not configured in nativeavailable > at gnu.io.RXTXPort.nativeavailable(Native Method) > at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1410) > at java.io.FilterInputStream.available(FilterInputStream.java:146) > > In Java, we see: > protected native int nativeavailable() throws IOException; > > Restart of the application solves the problem. > > The keyspan rs232-usb device goes to a powered hub....which lost power. > > The keyspan device thus goes off-line and then back on-line. The > mac is a lap-top (with batteries that work OK). > > Perhaps we can call this the Pop-Up usb error (since the device is > essentially hot-plugged). > > I suspect that this is the case of a device that disappears and then > re-appears. RXTX is probably not robust in the face of changes > like this. And to make it robust might require lots of effort and thought. > > Is this a hard problem to address? > It would require some refactoring. The nativeAvailable is on a seperate thread. The port is used by two threads (sometimes three). I'm guessing we could throw a new event type which would shut down the event loop and reopen the port and restart the eventThread. We have a couple ideas bouncing around. Perhaps it is time to start gathering requirements then look at functionality and architecture. The other 'usb' that would have requirements is bluetooth which 'vanishes.' -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sat May 10 16:39:57 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 10 May 2008 16:39:57 -0600 (MDT) Subject: [Rxtx] windows 64 bit support In-Reply-To: <549303.86192.qm@web54606.mail.re2.yahoo.com> References: <549303.86192.qm@web54606.mail.re2.yahoo.com> Message-ID: On Sat, 10 May 2008, Tyler Anderson wrote: > I know this has been asked about in the past. I'm considering using rxtx for an applet, and am > wondering if 64-bit xp and vista support is at least in the works, and if it will be supported in > the foreseeable future. > As far as I know, 32 bit vista works. 64 bit windows will require making termios.c 64 bit safe. Since the rest already works on 64 bit solaris and linux, I don't expect any problems. I'll look at the 64 bit mingw in time if nobody gets to it. -- Trent Jarvi tjarvi at qbang.org From zach at sensinode.com Sat May 17 15:54:22 2008 From: zach at sensinode.com (Zach Shelby) Date: Sun, 18 May 2008 00:54:22 +0300 Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib Message-ID: <482F540E.7060601@sensinode.com> Hi, Was happy to see the new JDK 1.6 release for Leopard from Apple. However the 64-bit only nature of the release causes headaches for RXTX's jnilib. Found a fix for 2.1.7r2: Symptom: java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading gnu.io.RXTXCommDriver Fix: Build a new jnilib from the 2.1.7r2 source with 3 architectures. ./configure Then edit the Makefile: - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS - Also add it in the cc -bundle lines This builds the jnilib in all the architectures, which is required by this JDK 1.6. However, now that this nice bug is out of the way for me, jnilib is crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I was getting "Serial port is open" errors, but after fixing the locks (/var/lock instead of /var/spool/uucp) I get a bit further but it now crashes on the first port read with a segmentation fault. Transmit seems to work OK (at least once): May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Serialport: /dev/tty.Bluetooth-Modem May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Starting receive method for Router 0 Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Writing reset to N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: No data available from N600 May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog INFO: Trying to read reset reply from N600 Invalid memory access of location 24e4b7c8 rip=23aa97d8 First transmit works (I get the command over the port), seems that the first read comes up empty, and then the next read crashes. This happens consistently, and diabling locks doesn't help. Anybody seen this kind of invalid memory access on read before? Thanks, Zach -- Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com From tjarvi at qbang.org Sat May 17 16:12:23 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 17 May 2008 16:12:23 -0600 (MDT) Subject: [Rxtx] Mac 10.5.2 + JDK 1.6 (64-bit) jnilib In-Reply-To: <482F540E.7060601@sensinode.com> References: <482F540E.7060601@sensinode.com> Message-ID: On Sun, 18 May 2008, Zach Shelby wrote: > Hi, > > Was happy to see the new JDK 1.6 release for Leopard from Apple. However > the 64-bit only nature of the release causes headaches for RXTX's > jnilib. Found a fix for 2.1.7r2: > > Symptom: > java.lang.UnsatisfiedLinkError: > /Library/Java/Extensions/librxtxSerial.jnilib: thrown while loading > gnu.io.RXTXCommDriver > > Fix: > Build a new jnilib from the 2.1.7r2 source with 3 architectures. > ./configure > Then edit the Makefile: > - Add "-arch x86_64 -arch i386 -arch ppc" to CFLAGS > - Also add it in the cc -bundle lines > > This builds the jnilib in all the architectures, which is required by > this JDK 1.6. > > However, now that this nice bug is out of the way for me, jnilib is > crashing. Anybody have RXTX working on 10.5.2 with JDK 1.6? At first I > was getting "Serial port is open" errors, but after fixing the locks > (/var/lock instead of /var/spool/uucp) I get a bit further but it now > crashes on the first port read with a segmentation fault. Transmit seems > to work OK (at least once): > > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Serialport: /dev/tty.Bluetooth-Modem > May 18, 2008 12:50:29 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Starting receive method for Router 0 > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > RXTX Warning: Removing stale lock file. /var/lock/LK.003.017.002 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Writing reset to N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > May 18, 2008 12:50:32 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: No data available from N600 > May 18, 2008 12:50:33 AM com.sensinode.ewsn.NodeView.NVLogger nvLog > INFO: Trying to read reset reply from N600 > Invalid memory access of location 24e4b7c8 rip=23aa97d8 > > First transmit works (I get the command over the port), seems that the > first read comes up empty, and then the next read crashes. This happens > consistently, and diabling locks doesn't help. Anybody seen this kind of > invalid memory access on read before? > > Thanks, > Zach > > Hi Zach, Thanks for sharing the fix. The crash sounds familiar. I may have resolved that for 64 bit linux/Solaris. The problem was that we stored information on the Java side that was used to exchange pointers to 'eis' between threads. This was stored as a 32 bit value.... This is in RXTXPort.java. eis is the 'event info struct' which contains information like where the JVM is. I think if you look at the 2.1 CVS source, you will find a fix. Note that the 2.1 source is on a branch as documented on http://www.rxtx.org/cvs.html. You can probably just cvs login (pw mousy) and cvs update as we ship the CVS info. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 12:12:33 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 14:12:33 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? Message-ID: <48307191.8070704@gatworks.com> tried using the mailing list ARChives. last entry in - 2005-03-01 - 2005-04-01 (57 messages) Broken? Not collecting anymore? From tjarvi at qbang.org Sun May 18 17:42:59 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 17:42:59 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <48307191.8070704@gatworks.com> References: <48307191.8070704@gatworks.com> Message-ID: On Sun, 18 May 2008, U. George wrote: > tried using the mailing list ARChives. last entry in - > 2005-03-01 - 2005-04-01 (57 messages) > > Broken? Not collecting anymore? http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html Looks like it is working. Follow the link under my sig. If you mean MARC, then yes... I did try to contact them but never heard back. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Sun May 18 17:58:56 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 19:58:56 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> Message-ID: <4830C2C0.5050002@gatworks.com> www.rxtx.org -> mail list -> searchable archive only goes to 2005-04-01. Trent Jarvi wrote: > On Sun, 18 May 2008, U. George wrote: > >> tried using the mailing list ARChives. last entry in - >> 2005-03-01 - 2005-04-01 (57 messages) >> >> Broken? Not collecting anymore? > > > http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html > > Looks like it is working. Follow the link under my sig. > > If you mean MARC, then yes... I did try to contact them but never heard > back. > > -- > Trent Jarvi > tjarvi at qbang.org > > > From tjarvi at qbang.org Sun May 18 18:33:02 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 18 May 2008 18:33:02 -0600 (MDT) Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: <4830C2C0.5050002@gatworks.com> References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: Ah, Thanks George. That is a handy little search box and worth keeping. I stuck it there as an experiement but it worked out. We should put one in the wiki too. The htdig application was segfaulting while indexing via cron. I've fixed that. It sould update everyday again. I triggered a run and will make sure it completes. Everything in the rxtx pipermail archive should be searchable tomorrow or sooner. On Sun, 18 May 2008, U. George wrote: > www.rxtx.org -> mail list -> searchable archive > only goes to 2005-04-01. > > > > Trent Jarvi wrote: >> On Sun, 18 May 2008, U. George wrote: >> >>> tried using the mailing list ARChives. last entry in - >>> 2005-03-01 - 2005-04-01 (57 messages) >>> >>> Broken? Not collecting anymore? >> >> >> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >> >> Looks like it is working. Follow the link under my sig. >> >> If you mean MARC, then yes... I did try to contact them but never heard >> back. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> > > > From netbeans at gatworks.com Sun May 18 18:36:19 2008 From: netbeans at gatworks.com (U. George) Date: Sun, 18 May 2008 20:36:19 -0400 Subject: [Rxtx] RXTX archives: last entry in 2005? In-Reply-To: References: <48307191.8070704@gatworks.com> <4830C2C0.5050002@gatworks.com> Message-ID: <4830CB83.3020307@gatworks.com> BTW: I dont seem to be getting my e-mails returned to me through the mail list. They seem to be getting to u, but not sure if you are getting it directly, or through the subscription list. Trent Jarvi wrote: > > Ah, > > Thanks George. > > That is a handy little search box and worth keeping. I stuck it there > as an experiement but it worked out. We should put one in the wiki too. > > The htdig application was segfaulting while indexing via cron. I've > fixed that. It sould update everyday again. I triggered a run and will > make sure it completes. Everything in the rxtx pipermail archive should > be searchable tomorrow or sooner. > > On Sun, 18 May 2008, U. George wrote: > >> www.rxtx.org -> mail list -> searchable archive >> only goes to 2005-04-01. >> >> >> >> Trent Jarvi wrote: >>> On Sun, 18 May 2008, U. George wrote: >>> >>>> tried using the mailing list ARChives. last entry in - >>>> 2005-03-01 - 2005-04-01 (57 messages) >>>> >>>> Broken? Not collecting anymore? >>> >>> >>> http://mailman.qbang.org/pipermail/rxtx/2008-May/2432118.html >>> >>> Looks like it is working. Follow the link under my sig. >>> >>> If you mean MARC, then yes... I did try to contact them but never >>> heard back. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> >> >> >> > > From jimmy.lee at emotum.com Mon May 19 01:41:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 17:41:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Message-ID: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Hi all, Using rxtx on the OS X Leopard, Java 1.5 if it matters. I have problem with NoSuchPortException. My app has a loop that tries to use a particular port: CommPortIdentifier port = CommPortIdentifier.getPortIdentifier(portName); If I have the USB device plugged in BEFORE the app lauches, everything works fine. I can remove it, and insert it, and the loop that checks for it will eventually work when the USB device is ready. However, if start the app without the USB device plugged in, then plug it in after, I continue to get NoSuchPortException forever. If I do a "ls /dev", the port is there but the app still continues to throw NoSuchPortException. Any ideas? Greatly appreciated, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080519/b45d20ca/attachment-0035.html From greg.johnson at manchester.ac.uk Mon May 19 02:22:08 2008 From: greg.johnson at manchester.ac.uk (Greg Johnson) Date: Mon, 19 May 2008 10:22:08 +0200 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a ?ls /dev?, the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From jimmy.lee at emotum.com Mon May 19 03:37:11 2008 From: jimmy.lee at emotum.com (Jimmy Lee) Date: Mon, 19 May 2008 19:37:11 +1000 Subject: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem In-Reply-To: References: <002001c8b983$b6982de0$23c889a0$@lee@emotum.com> Message-ID: <002b01c8b993$eb965c50$c2c314f0$@lee@emotum.com> Hi Greg, Thanks for the prompt reply. That worked really well. Regarding disconnecting the USB port causing crashes, that used to happen for me too. Invalid memory access or something? I've been using the compiled .jnilib from http://code.google.com/p/ardrumo/ and the crash hasn't occurred in a while. Not sure if that has anything to do with it or not. Thanks again for your help! Jimmy -----Original Message----- From: Greg Johnson [mailto:greg.johnson at manchester.ac.uk] Sent: Monday, 19 May 2008 6:22 PM To: Jimmy Lee Cc: rxtx at qbang.org Subject: Re: [Rxtx] OS X - compiled from CVS - NoSuchPortException - USB modem Hi Jimmy, Yes, you have to do a fresh call to enumerate the ports - you have a pre-insertion list which doesn't know about the USB dongle. Something like: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); // should refresh to pickup the USB ports HashSet spnew = new HashSet(); // put the valid port identifiers into a hashmap while (portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); String portName = portId.getName(); if ((portId.getPortType() == CommPortIdentifier.PORT_SERIAL) && (!portName.toLowerCase().contains("bluetooth") ) && (portName.toLowerCase().contains("tty") || portName.toLowerCase().contains("com"))) { spnew.add(portName); } } (this is verbatim from my code - I do some horrible stuff to put all the new ports in a set, do some intersection logic with the ports that were already detected, and ensure that I open a monitor for each port I can see, but you can forget about that - the first line is the one you care about) I've got to say that dealing with USB ports can be quite frustrating. There appears to be a variable but significant (>1000ms) delay that I need between enumerating a new USB port and opening it successfully. In addition, disconnecting a USB port causes complete chaos - usually it kills my app. Hope that helps, greg ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 On 19 May 2008, at 09:41, Jimmy Lee wrote: > Hi all, > > Using rxtx on the OS X Leopard, Java 1.5 if it matters. > > I have problem with NoSuchPortException. > > My app has a loop that tries to use a particular port: > > CommPortIdentifier port = > CommPortIdentifier.getPortIdentifier(portName); > > If I have the USB device plugged in BEFORE the app lauches, > everything works fine. I can remove it, and insert it, and the loop > that checks for it will eventually work when the USB device is ready. > > However, if start the app without the USB device plugged in, then > plug it in after, I continue to get NoSuchPortException forever. If > I do a "ls /dev", the port is there but the app still continues to > throw NoSuchPortException. > > Any ideas? > > Greatly appreciated, > Jimmy > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx ------------------------------------------------------------------------- Greg Johnson Research Fellow at University of Manchester Scientific Collaborator at ESRF - European Synchrotron greg.johnson at esrf.fr greg.johnson at ieee.org +33 (0)4 76 88 28 37 From will.tatam at red61.com Mon May 19 11:44:54 2008 From: will.tatam at red61.com (Will Tatam) Date: Mon, 19 May 2008 18:44:54 +0100 Subject: [Rxtx] Windows XPe Message-ID: <4831BC96.5060802@red61.com> Has anyone managed to get RXTX to run under Windows XP embedded ? When i tried i got some error about depenancies of the dlls being missing It looked like the RXTX dlls are trying to like to some standard windows dll's that aren't present. -- Will Tatam Systems Architect Red61 0845 867 2203 ext 103 From tjarvi at qbang.org Tue May 20 18:29:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 20 May 2008 18:29:21 -0600 (MDT) Subject: [Rxtx] Windows XPe In-Reply-To: <4831BC96.5060802@red61.com> References: <4831BC96.5060802@red61.com> Message-ID: On Mon, 19 May 2008, Will Tatam wrote: > Has anyone managed to get RXTX to run under Windows XP embedded ? When i > tried i got some error about depenancies of the dlls being missing > > It looked like the RXTX dlls are trying to like to some standard windows > dll's that aren't present. > > I'm guessing you need to compile rxtx for that platform. It wont be easy but should be possible. Double check that there isnt a package you need to install for xpe support. I've never used one. -- Trent Jarvi tjarvi at qbang.org From j.kenneth.gentle at acm.org Wed May 21 06:21:21 2008 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Wed, 21 May 2008 08:21:21 -0400 Subject: [Rxtx] Windows XPe In-Reply-To: References: <4831BC96.5060802@red61.com> Message-ID: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Apparently I forgot to post my findings back to the List - my apologies all. The addition of CRTDLL.DLL seems to have corrected the earlier problem of the RXTX native library failing to load. Did you have to specifically add CRTDLL as a "component" to the XP/E Image, or did you copy it from another directory on the image? If it already exists in the XP/E Image then all I should have to do is include it in the '-Djava.library.path="../lib" ' when starting up the JRE. [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's /lib directory seems to work] Attached is the set of minimum requirements for the XP/Embedded JRE as specified by Sun. Please note that we're not using TCP/IP networking (at the moment anyway) nor the Windows Installer Service. Below those requirements is a response from the RXTX maintainer concerning running on Windows XP/Embedded - no one had any experience with it. The list of calls are all windows specific APIs - the RXTX components use standard C runtime library calls for everything else. The stuff in RED is critical. The other is "nice" - I believe that what we're trying won't need the TCP/IP networking, but there is a JRE requirement for it. Let me know if it is not present. ======================================================================= Platform Minimum Requirements ======================================================================= Embedded J2SE(TM) for Windows XP-E has been certified to run on an x86 compatible target platform running Windows XP Embedded containing the following components: - Windows Application Compatibility Macro Component - Basic TCP/IP Networking - TCP/IP Networking with File Sharing and Client for MS Networks - Windows Installer Service (If self extracting .exe bundles is used for installation) - User Interface Core To run the Embedded Java Runtime (JRE), Sun recommends a system with a minimum of 64M of RAM, with at least 10MB of available RAM for each Java JRE process and 64MB of swap space. The Embedded JRE disk or FLASH space requirements for the complete JRE is 39MB. ======================================================================== >From Trent Jarvi, maintainer of the RXTX library: ... There are only a hand full of api calls rxtx makes to w32. They are basic functions like: EscapeCommFunction CreateFile ClearCommError GetCommTimeouts GetCommState GetTickCount WaitForSingleObject WaitCommEvent WriteFile PurgeComm SetCommMask SetCommState ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080521/cb2fdf9c/attachment-0033.html From will.tatam at red61.com Thu May 22 11:01:22 2008 From: will.tatam at red61.com (Will Tatam) Date: Thu, 22 May 2008 18:01:22 +0100 Subject: [Rxtx] Windows XPe In-Reply-To: <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> References: <4831BC96.5060802@red61.com> <670b66630805210521k5b5e8193u2aef7e0e84ab7e6@mail.gmail.com> Message-ID: <4835A6E2.3060400@red61.com> Thanks, that worked perfectly Ken Gentle wrote: > Apparently I forgot to post my findings back to the List - my > apologies all. > > > The addition of CRTDLL.DLL seems to have corrected the earlier problem > of the RXTX native library failing to load. Did you have to > specifically add CRTDLL as a "component" to the XP/E Image, or did you > copy it from another directory on the image? If it already exists in > the XP/E Image then all I should have to do is include it in the > '-Djava.library.path="../lib" ' when starting up the JRE. > > [Note 2008-05-15: Dropping CRTDLL.DLL into the Java installation's > /lib directory seems to work] > > Attached is the set of minimum requirements for the XP/Embedded JRE as > specified by Sun. Please note that we're not using TCP/IP networking > (at the moment anyway) nor the Windows Installer Service. > > Below those requirements is a response from the RXTX maintainer > concerning running on Windows XP/Embedded - no one had any experience > with it. The list of calls are all windows specific APIs - the RXTX > components use standard C runtime library calls for everything else. > > The stuff in RED is critical. The other is "nice" - I believe that > what we're trying won't need the TCP/IP networking, but there is a JRE > requirement for it. Let me know if it is not present. > ======================================================================= > Platform Minimum Requirements > ======================================================================= > Embedded J2SE(TM) for Windows XP-E has been certified to run on > an x86 compatible target platform running Windows XP Embedded > containing the following components: > > - Windows Application Compatibility Macro Component > - Basic TCP/IP Networking > - TCP/IP Networking with File Sharing and Client for MS Networks > - Windows Installer Service (If self extracting .exe bundles is used > for installation) > - User Interface Core > > > To run the Embedded Java Runtime (JRE), Sun recommends a > system with a minimum of 64M of RAM, with at least 10MB of available > RAM for each Java JRE process and 64MB of swap space. > > The Embedded JRE disk or FLASH space requirements for the complete > JRE is 39MB. > ======================================================================== > > > From Trent Jarvi, maintainer of the RXTX library: > ... > There are only a hand full of api calls rxtx makes to w32. They are > basic > functions like: > > EscapeCommFunction > CreateFile > ClearCommError > GetCommTimeouts > GetCommState > GetTickCount > WaitForSingleObject > WaitCommEvent > WriteFile > PurgeComm > SetCommMask > SetCommState > > ... > > > -- Will Tatam Systems Architect Red Sixty One LTD 0845 867 2203 ext 103 From jredman at ergotech.com Thu May 22 19:47:33 2008 From: jredman at ergotech.com (Jim Redman) Date: Thu, 22 May 2008 19:47:33 -0600 Subject: [Rxtx] already loaded in another classloader Message-ID: <48362235.5020604@ergotech.com> RXTX Gurus, OK, this is (hopefully) my last barrier to having RXTX running under Mono/IKVM on the NSLU2 ARM9 platform. OS is Debian, a full install. This all runs correctly on FC8. Any pointers/suggestions appreciated. The application gets to the point where it starts to access serial ports and I get this: Experimental: JNI_OnLoad called. java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader thrown while loading gnu.io.RXTXCommDriver Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for gnu.io.CommPortIdentifier ---> java.lang.UnsatisfiedLinkError: Native library ./librxtxSerial.so already loaded in another classloader--- End of inner exception stack trace --- at com.ergotech.vib.ports.SerialWrapper.setPort (Int32 ) [0x00000] The native libraries in play are: libikvm-native.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped librxtxSerial.so: ELF 32-bit LSB shared object, ARM, version 1 (ARM), not stripped Thanks, Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Loi.TRAN at weatherford.com Fri May 23 12:14:24 2008 From: Loi.TRAN at weatherford.com (TRAN, Loi X.) Date: Fri, 23 May 2008 13:14:24 -0500 Subject: [Rxtx] (no subject) Message-ID: We're attempting to use a Silicon Labs part number CP2103 which looks like a RS232 port. The part itself is a USB port. It's currently run at 460.8Kbaud. Using the class below, we sent out an array of bytes of length defined by what's passed in. We have a problem in that the data being sent out of the USB port has wide gaps in time (~20 - 30 milliseconds) between each byte sent. How can we force the bytes to be burst out with minimal delay (<5 ms) between each byte? Has anyone experienced this problem? import java.io.IOException; import java.io.OutputStream; public class SerialWriter implements Runnable { private OutputStream out; private int count; private byte[] c; public SerialWriter ( OutputStream out, byte[] c ) { this.out = out; this.c = c; } public void run () { try { for (count = 0; count < c.length; count++) out.write(c[count]); } catch (IOException e) { e.printStackTrace(); } } } =============================== CONFIDENTIAL & PRIVILEGED COMMUNICATION The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity addressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message, and then delete it from your system. The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, or the cons