From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on my Windows 7 machine, as per the Windows installation instructions. I've also modified the java applet (replacing all instances of javax.comm with gnu.io.*) on the serverside. The java applet was working with javax.comm on Windows XP, but we now require Win7 compatitibility, hence the change to rxtx. However, when loading the applet I get the following message in the Console: Error Loading Driver http://dpaste.com/531176/ (verbose output) I believe that I've installed it correctly, though could do with some help on troubleshooting this further. i.e. How to get more information on why the driver failed to load. Regards, Andy Loughran From Kustaa.Nyholm at planmeca.com Tue Apr 12 04:27:07 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 13:27:07 +0300 Subject: [Rxtx] Announcing PureJavaComm Message-ID: Hi List, I could not resist so I had to create a Pure Java implementation of JavaComm SerialPort with no C-code or JNI in sight! If you are interested, please go to my website at: http://www.sparetimelabs.com/ and select 'PureJavaComm' from the navigation on the left. br Kusti From george.dma at gmail.com Tue Apr 12 06:19:35 2011 From: george.dma at gmail.com (George H) Date: Tue, 12 Apr 2011 15:19:35 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Nice, I'm sure there will be many who will try it out. Good job on that. I'll have to try it out. Though I was reading the site... I don't think it can be called "pure java" ... You are still depending on libraries that use native code. Just to give an example... It's like I took RXTX and added my own java code on it and then called my lib "pure java" ... this is regardless if I used JNA or not. Pure java is completely omiting the whole C/JNA/JNI part completely, just relying on the JVM it self. Btw, it's still cool that now there are 3 projects doing serial io for java apps so at least there is some diversity. -- George H george.dma at gmail.com On Tue, Apr 12, 2011 at 1:27 PM, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damorales at gmail.com Tue Apr 12 07:16:10 2011 From: damorales at gmail.com (Daniel Morales Salas) Date: Tue, 12 Apr 2011 09:16:10 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: This really sounds great ... I will take a closer look this weekend. Compiling c libraries is very annoying everytime you want to install "our" software in different distros or whatever so JNA approach sounds really useful. Big thanks for your effort and I hope more developers come into your project. Greetings! 2011/4/12 Kustaa Nyholm > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Atte: Daniel Dario Morales Salas Ingeniero Civil en Computaci?n e Inform?tica Tel?fono: 02 684 3417 Celular: 09 643 1802 Santiago, Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From thompd at gmail.com Tue Apr 12 07:38:56 2011 From: thompd at gmail.com (Dave Thompson) Date: Tue, 12 Apr 2011 09:38:56 -0400 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: I'm definitely looking at this today for running on the Mac. If this works, you will be my hero. Cheers! On Tue, Apr 12, 2011 at 09:16, Daniel Morales Salas wrote: > This really sounds great ... I will take a closer look this weekend. > Compiling c libraries is very annoying everytime you want to install "our" > software in different distros or whatever so JNA approach sounds really > useful. > > Big thanks for your effort and I hope more developers come into your > project. > > Greetings! > > > 2011/4/12 Kustaa Nyholm > >> Hi List, >> >> I could not resist so I had to create a Pure Java implementation of >> JavaComm SerialPort >> with no C-code or JNI in sight! >> >> If you are interested, please go to my website at: >> >> http://www.sparetimelabs.com/ >> >> and select 'PureJavaComm' from the navigation on the left. >> >> br Kusti >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > > -- > Atte: > Daniel Dario Morales Salas > Ingeniero Civil en Computaci?n e Inform?tica > Tel?fono: 02 684 3417 > Celular: 09 643 1802 > Santiago, Chile > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Apr 12 08:23:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 17:23:57 +0300 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: Message-ID: On 4/12/11 16:38, "Dave Thompson" wrote: >I'm definitely looking at this today for running on the Mac. >If this works, you will be my hero. > >Cheers! Good, let me know WHEN (not IF) you find issues. BTW you and others, please don't CC Pete whom I unfortunately CC's in my announcement. br Kusti From bschlining at gmail.com Tue Apr 12 09:32:44 2011 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 12 Apr 2011 08:32:44 -0700 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: Very cool. I'll try to take it for a spin. B On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Apr 12 14:27:16 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Apr 2011 22:27:16 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: <20110412202716.GB1190@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Tue, Apr 12, 2011 at 07:48 +0300: > > When all FourTireCars have four tires, then there must be not > > specialisation of a FourTireCar with only three tires and > > getFourthTire shall not throw TireNotAvailableException :-) > > See InputStream.reset(). > > Nice parallel! However, behind all stupid (API) decision you > often find a 'good' and pragmatic reason. Like timeouts on > InputStream return without data which is against the spec per > se. Outside Java, probably ;-) SCNR. For reset(), I think it is rarely used. I'm afraid it was just added because someone wanted the famous `ungetchar' and thought this would be `a clean alternative'. Anyway. > >I don't think this is what the Java doc intends to say. I think > >what it means is that you cannot expect that, because the > >InputStream interface (which IMHO is very weak anyway due to its > >design Bugs like void available(void) etc) does not guarantee > >that. It tells, more or less, "by accident, the base class, which > >does almost nothing, is thread safe, whatever this means, but sub > >classes may do something completely different, throw > >NotImplemented, ConcurrentAccessException or even deliver > >duplicated phantom data to multiple threads. > > Yes, you could (probably should!) read it like that but it depends > on the reader. A casual reader might take it at face value > and rely on th ThisInputStream IS-A InputStream therefore everything > it says the InputStream javadoc applies. Yes, of course, this is reasonable and what interfaces and specs are for, sure. Of course depends how to interpret what Java doc says. Does it say "*This* implementation does XYZ" or really "This interface requires XYZ" (which IMHO would imply that all subclasses have to fullfill this, and throwing IOError if reset is not implemented would be no option). Of course also here your argument (being pragmatic where it is suited) applies; there might be very specific InputStreams behaving differently. For example, if working via RMI, JNI or CORBA, internally some very different exceptions could be thrown and converted to RuntimeExceptions (in situations, where no InputStream derivation could do anything better, this IMHO would be pragmatic and thus OK). Well, *I* think, serial ports simply are no InputStreams. Maybe someone can see a serial port as something that - among other things - HAS an InputStream (like rxtx). Here I think it should be supported to use the InputStream and the OutputStream of the same physical port in different threads. Since the application can consider both being independent (different instances, so why lock? And if locking different instances, what exactly to lock how?), if concurrency between InputStream and OutputStream needs synchronization, then I think the implementations of that Streams had to do it (not the application). Also when the Streams need synchronization with something else (like some PortManager). > >Interesting is ByteArrayInputStream, which works on a foreign > >byte[] (not copied) and thus can make no guarantee about reset() > >behavior (another thread can modify byte[] between mark() and > >reset() and surely read will return different data I think. > > And other example of the API issues! However you this too falls > under the question what thread-safety means in this context. I think not API but implementation: it is oversimplified. It does not fulfill the InputStream definition. Of course it is clear why (this is a simple thing to be used for a simple InputStream, a kind of adapter to produce some bytes, suited for testing for example). Just BTW: here, I think reset() and mark() are wrong. They do not belong to InputStream. They could be MarkableInputStream. Or simply have an adapter that internally buffers the last read byte and/or add `ungetchar()' to the interface or so. Don't know if most recent Java has `Traits' (have to work with old versions here). If so, MarkableInputStream IMHO would be a good `Trait'. Single-Inheritance-Derivation is a bit to small for such things (and multi-inheritance-derivation has other [MAJOR] issue etc). > >The reasonable expectation IMHO is that one and only one of the > >read invoking threads get a particular piece of data (i.e. each > >received byte is delivered to exactly one caller), if having a > >happens-before relationship the caller threads could even interpret > >the bytes in the correct order :-) > > Yes, that is a reasonable in expectation in my view. > > >Even if internally it's safe, in case of serial I/O the returned > >data would be difficult to handle (unless the protocol has single > >byte command/responses) I think. > > Agree, my reasoning is that it is not very reasonable to expect > (and support) multiple threads to read from the same input stream > without an external mutex, and hence, in a way, this in contradiction > with my/your statement in the above paragraph: if the expectation > is that you need an external synchronization anyway, why bother > with it inside the InputStream....!? Not for this usecase (I agree that it does not seem an important one), but for e.g. concurrent associated OutputStream usage. > >Yes, or I think better close waiting for the read to finish, > >would be safer regarding to the contract of the API, but in > >practice with the disadvantage that a intended brute-force-close > >would not abort the read, which can make sense when for example > >the user closes the application. > > >From the implementation point of view I get constant crashes in > Windows if I do not let an async call I/O return from the > WaitMultipleObjects call. Which is a bit of a nuisance since I > do think many people expect close() to block even briefly. But > then again there is not promise about that in the javadoc I expect close() to instantly close, aborting pending requests instantly, with `instantly' meaing `less than a second' or so. If OS supports draining or alike, application shouldn't notice it. When called from Java, the native implementation IMHO shall not crash however it is called as long as syntactically correct from Java, because Java also does not `crash' (to allow some diagnostics), which is an ideal aim, not a practical one, I think. Access to members etc could and should be forced atomic by mutexes, I think. This would ease usage and limit damage if used wrongly. Of course this relies that the overheads are not too significant to forbid that (the mutexes add extra overhead, of course, but I would guess not a significant amount of extra time or CPU). A more practical way could be to synchronize native code calls from the java adapter classes that call the JNI impls. > >> Going on, thinking out loud. > >> > >> It should be perfectly ok to use one thread to operate the > >> OutputStream and another the InputStream. > > > >You mean this as requirement? > >I think there is definitely no such guarantee. > >Even here, because both, I think, are just wrappers for something > >that communicates and they share the comm resource (file handle). > > What I ment was that the user of [RXTX] is perfectly reasonable if > he thinks that he can call write from one thread while an other thread > is performing a read and this should be supported. ahh, ok! Yes, then I agree. > > You assume, you can open a port only once? > > Why isn't it allowed to open COM1 twice and use one only for > > reading and the other only for writing? > > Well, I'm actually going to leave this 'implementation defined'. I think I would try to avoid this, because having races here (opening-right-before-or-after-close) can be hard to debug otherwise, I think. If possible. For sake of simplicity I think I would implement it in a way that opening twice is not possible. If plenty amount of time I would implement to unconditionally allow this, even if the OS does not allow this (by having two java-world instances using the same native-world instance, for example). This would look better and more functional, but for a price (probably not worth the advantage, if any, exept of course someone has such requirements due the requirements of his project). > I don't know if in Windows you can open the same port twice even > if other is read and another is write (maybe I should check) but > in *nix it seems there is no mechanism to guarantee mutual exclusion > if an other application is playing ball, so I won't bother. > > May change my mind about that though. One argument I would use is that the Java API (or rxtx, in this case) should abstract from the OS: wherever it runs, it should behave in the same way. Here is should be fairly simple (just having some port in use flag). Isn't this what rxtx is doing anyway? When abstracting I/O I think it is visible that for other streams often you also can have just one instance `open' at a time (I would call it `existent', in spirit of RAII). For example compare with TCP/IP sockets. You could connect to the same server twice, but both connections would not be related (e.g. you can NOT write the one but read the other). Or imagine even you are a TCP /server/. If you try to connect a second time, server socket would wait for a second client :) Probably I oversimplify. Depends a lot of the project / task of course. > >I think signals do; having a DCD observing thread for example. > >Especially if writing big blocks of data it might be important. > >API / impl should define what happens when signals change. > > Sorry I was not clear, I meant setting the same signal from > two threads without some external sync in the application, however, > this is a non issue in the implementation I think. ahh OK, I did not differentiate signals from two threads plus a comm thread from a signal and a comm thread. I think the latter sometimes could be reaonable / helpful. Sometimes. But I guess in practice most applications simply wouldn't care. > >I think, here nothing happens, but this might be unexpected. If > >you have a modem and you send data, as soon as DCD gets low the > >write should stop with some CARRIER LOST - but how to implement > >best and generic? Is this even possible with InputStream? > > I'm not sure I follow you here. I mean, if you let's say continuesly read some InputStream which is associated via serial POTS / PSTN modem (and maybe some other thread from time to time sends some ACKs or so) and then the modem line gets lost and the modem replies with "CARRIER LOST", without evaluating signals the application would read this "CARRIER LOST" and would not know if that is data from the modem itself and would consider it data from the remote side. Even worse if the application scans for "CARRIER LOST" to be able to abort if it is received (without checking control lines) which leads to great effects if the remote side (and not the modem) really sends "CARRIER LOST" (for example, when transmitting this mail which contains the string as literal :)). I know cases where this happened in practice. > >I think an idea could be to define that read(bytes[]) returns on > >every signal change to allow a caller to query signal state. > > Ok, got it know. Hmmm, sort of makes sense, but I don't see > how to implement that reliably and reasonably in this frame > (JavaComm) framework. I think, no problem for `int read(bytes[]...)' - it would just return an appropriate length, but a problem for `byte read(void)'. But I think I already wrote that I consider the existence of `byte InputStream.read(void)' a big mistake anyway :) > >> Like InputStream.read(), OutputStream.write() makes no sense to > >> me to call this from multiple streams unless you have some mutex > >> in place in the calling code, > > Sorry, was not clear here, what I meant that it is not reasonable to > do read from multiple threads (without some external mutex) but > it of course reasonable for one thread to read and other write. Ahh yes, I see and agree :) oki, Steffen From klaus.kloos at gmx.de Wed Apr 13 03:45:15 2011 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Wed, 13 Apr 2011 11:45:15 +0200 Subject: [Rxtx] Announcing PureJavaComm In-Reply-To: References: Message-ID: <7197B7FA-EE17-4794-887F-E77F294E3C6D@gmx.de> Hello Such a nice project .... I will try to get it working on OSX an WinXP. Greetings Klaus > > > On Tue, Apr 12, 2011 at 03:27, Kustaa Nyholm wrote: > Hi List, > > I could not resist so I had to create a Pure Java implementation of > JavaComm SerialPort > with no C-code or JNI in sight! > > If you are interested, please go to my website at: > > http://www.sparetimelabs.com/ > > and select 'PureJavaComm' from the navigation on the left. > > br Kusti > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Escalona at digi.com Wed Apr 13 04:09:36 2011 From: David.Escalona at digi.com (Escalona, David) Date: Wed, 13 Apr 2011 12:09:36 +0200 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <4D5F0080.2060601@employees.org> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> Message-ID: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Having same issue here. Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. Any suggestion on this? -- David Escalona Software Engineer -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss Sent: s?bado, 19 de febrero de 2011 0:28 To: rxtx at qbang.org Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException will do, thanks... Andre-John Mas wrote: > The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . > > On 7-Feb-2011, at 14:00, afoss wrote: > > >> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >> >> Michael Erskine wrote: >> >>> On 7 February 2011 15:35, Andrew Foss wrote: >>> >>> >>>> Hello, >>>> >>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>> >>>> Whenever I try to access and serial devices, I get this; >>>> >>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>> :gnu.io.PortInUseException: Unknown Application >>>> >>>> I can use "screen" and access the devices ok from a /bin/sh. >>>> >>>> Any ideas or pointers? >>>> >>>> >>> Hi Andrew, >>> Can you be absolutely sure that the port is definitely not in use? (If >>> so, how are you checking, just out of interest?) >>> >>> Regards, >>> Michael Erskine. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Jayaprakash.Nevara at digi.com Fri Apr 15 02:28:18 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 13:58:18 +0530 Subject: [Rxtx] Is RXTX has been ported to ARM based platforms Message-ID: Hi, I am trying to interface a Serial device from Android, my android is running on Wi.IMX51 Connect Core platform. Do we have the RXTX serial libraries ported for Wi.IMX51 Connect core platform? If not how can we port the same? Please suggtest. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jayaprakash.Nevara at digi.com Fri Apr 15 02:35:32 2011 From: Jayaprakash.Nevara at digi.com (Nevara, Jayaprakash) Date: Fri, 15 Apr 2011 14:05:32 +0530 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package Message-ID: Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. Regards, Jayaprakash Nevara, Sr. Firmware Engineer Digi m2m Solutions India Pvt. Ltd. # 52/A, 100 Feet Road, 4 Block Koramangala Bangalore 560 034, India Direct: +91.80.4287.9826 Main: +91.80.4287.9888 Email: jayaprakash.nevara at digi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 05:51:33 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 07:51:33 -0400 Subject: [Rxtx] rxtx and WebStart Message-ID: <4DA83145.9030501@gmail.com> Hi all, I've been using rxtx for a couple years but am new to the list. I want to use WebStart to distribute a program using rxtx and looked at this helpful web page: http://rxtx.qbang.org/wiki/index.php/WebStart The bottom jnlp example has several lines for the native libraries. For instance, the one I'm using as my first test case: Can someone tell me, though, what are in the jar files? I simply jarred up the i686 libs but am not sure this is really correct: [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so While I have other jnlp set ups running, I have no luck with a simple rxtx app that communicates with a radio transceiver: java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) at java.security.AccessController.doPrivileged(Native Method) etc., etc... Are there any simple WebStart rxtx apps that can be used as a beginner's example? It will be great if I can get webstart working to support multiple platforms. Many thanks for any help! Mike From bartley at cmu.edu Fri Apr 15 06:22:17 2011 From: bartley at cmu.edu (Chris Bartley) Date: Fri, 15 Apr 2011 08:22:17 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: We use WebStart + RxTx and it works great. Here are some JNLPs you can look at: http://www.terk.ri.cmu.edu:8080/terk/apps/artsandbots.jnlp http://www.terk.ri.cmu.edu:8080/terk/apps/rxtx.jnlp And here's a pointer to the jarred native libs I use (look for rxtx-native-macosx.jar and rxtx-native-windows.jar): https://code.google.com/p/create-lab-commons/source/browse/#svn%2Ftrunk%2Fjava%2Flib%2Frxtx The README in that directory explains how I built, what differs, etc. Chris On Apr 15, 2011, at 7:51 AM, Mike Markowski wrote: > Hi all, > > I've been using rxtx for a couple years but am new to the list. > > I want to use WebStart to distribute a program using rxtx and looked at this > helpful web page: > > http://rxtx.qbang.org/wiki/index.php/WebStart > > The bottom jnlp example has several lines for the native libraries. For > instance, the one I'm using as my first test case: > > > > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > While I have other jnlp set ups running, I have no luck with a simple rxtx app > that communicates with a radio transceiver: > > java.io.FileNotFoundException: http://udel.edu/~mm/elecraft/k3info/K3info.jnlp > at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491) > at java.security.AccessController.doPrivileged(Native Method) > > etc., etc... > > Are there any simple WebStart rxtx apps that can be used as a beginner's > example? It will be great if I can get webstart working to support multiple > platforms. > > Many thanks for any help! > Mike > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From neil.benn at ziath.com Fri Apr 15 06:58:31 2011 From: neil.benn at ziath.com (Neil Benn) Date: Fri, 15 Apr 2011 13:58:31 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console Message-ID: Hello, When using RXTX it erports the version number to stdout on the console. Is there any way to stop that. My OS in Win (XP to 7, 32 and 64 bit) and my version is 2.1.7. Thanks? Cheers, Neil -- Neil Benn MSc Ziath Ltd Phone: +44 (0) 1223 655577 http://www.ziath.com *Please consider the environment before printing this email.* Follow us on Facebook or Twitter IMPORTANT NOTICE: This message, including any attached documents, is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Ziath Ltd immediately by email at info at ziath.com. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Fri Apr 15 07:24:36 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 15 Apr 2011 14:24:36 +0100 Subject: [Rxtx] Stopping version nubmer reporting to console In-Reply-To: References: Message-ID: On 15 April 2011 13:58, Neil Benn wrote: > Hello, > > ?????? When using RXTX it erports the version number to stdout on the > console.? Is there any way to stop that.? My OS in Win (XP to 7, 32 and 64 > bit) and my version is 2.1.7. Hi Neil, Redirect standard output (with System.setOut()) prior to pulling in the RXTX native library. Regards, Michael Erskine. From bschlining at gmail.com Fri Apr 15 09:40:28 2011 From: bschlining at gmail.com (Brian Schlining) Date: Fri, 15 Apr 2011 08:40:28 -0700 Subject: [Rxtx] rxtx and WebStart In-Reply-To: <4DA83145.9030501@gmail.com> References: <4DA83145.9030501@gmail.com> Message-ID: > > > > Can someone tell me, though, what are in the jar files? I simply jarred up > the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > Yes, that's correct. -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Fri Apr 15 11:27:23 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 15 Apr 2011 13:27:23 -0400 Subject: [Rxtx] rxtx and WebStart In-Reply-To: References: <4DA83145.9030501@gmail.com> Message-ID: <4DA87FFB.1010503@gmail.com> Thanks very much, both Chris and Brian! My app is now available across platforms and happily interacts with the transceiver. I greatly appreciate the speedy and helpful replies. And just in time to relax for the weekend. :-) Thanks again, Mike On 04/15/2011 11:40 AM, Brian Schlining wrote: > > > Can someone tell me, though, what are in the jar files? I simply jarred up the > i686 libs but am not sure this is really correct: > > [mm at qrn rxtx]$ jar tvf rxtx-comm-natives-linux-i686-32.jar > 0 Fri Apr 15 07:25:44 EDT 2011 META-INF/ > 71 Fri Apr 15 07:25:44 EDT 2011 META-INF/MANIFEST.MF > 60041 Mon Jan 30 02:23:42 EST 2006 librxtxParallel.so > 154682 Wed Feb 01 15:00:58 EST 2006 librxtxSerial.so > > > Yes, that's correct. > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com From ajmas at sympatico.ca Mon Apr 18 06:54:40 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Apr 2011 08:54:40 -0400 Subject: [Rxtx] MacOSX gnu.io.PortInUseException In-Reply-To: <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> References: <4D50113C.1070802@employees.org> <4D504137.4050402@employees.org> <4D5F0080.2060601@employees.org> <1FD68CB59C3190408725722FDA3E2C7301755BBC9BB8@dor-sms-exch01.digi.com> Message-ID: Use the latest version from source control. I suspect you are trying to use the version which is assuming the presence of a lock file for the serial port. On 13-Apr-2011, at 06:09, Escalona, David wrote: > Having same issue here. > > Mac OS 10.6.7 and port is in use while attempting to open it using rxtx. We have checked with "fuse" and port is not being used by any application. Furthermore, we can open it and write/receive using "screen" command without any problem. > > Any suggestion on this? > -- > David Escalona > Software Engineer > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of afoss > Sent: s?bado, 19 de febrero de 2011 0:28 > To: rxtx at qbang.org > Subject: Re: [Rxtx] MacOSX gnu.io.PortInUseException > > will do, thanks... > > Andre-John Mas wrote: >> The other way of checking is doing and 'lsof' on /dev/tty.usbserial-A600eIPU . >> >> On 7-Feb-2011, at 14:00, afoss wrote: >> >> >>> There was no /var/lock directory on my mac running 10.5.8, I've created it and chmoded it, but my guess is locking is done differently in this OS... >>> >>> Michael Erskine wrote: >>> >>>> On 7 February 2011 15:35, Andrew Foss wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've put RXTX-2.1-7 on my Mac 32bit OS X 10.5.8 >>>>> >>>>> Whenever I try to access and serial devices, I get this; >>>>> >>>>> java.io.IOException: Could not open port (/dev/tty.usbserial-A600eIPU) >>>>> :gnu.io.PortInUseException: Unknown Application >>>>> >>>>> I can use "screen" and access the devices ok from a /bin/sh. >>>>> >>>>> Any ideas or pointers? >>>>> >>>>> >>>> Hi Andrew, >>>> Can you be absolutely sure that the port is definitely not in use? (If >>>> so, how are you checking, just out of interest?) >>>> >>>> Regards, >>>> Michael Erskine. >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Wed Apr 20 08:04:34 2011 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 20 Apr 2011 10:04:34 -0400 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, but uses a separate name space and uses a different implementation. What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? Andre From Cougar at CasaDelGato.Com Wed Apr 20 10:37:31 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 09:37:31 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF0BCB.4060300@CasaDelGato.Com> Well, since Android devices don't have serial ports, it doesn't seem relevant. On 4/20/2011 7:04 AM, Andre-John Mas wrote: > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > >> Hi Is RXTX is a replacement for javax.comm package or we need both these in order to work with serial ports from java / android. > RXTX is a separate implementation of the javax.comm API. The API presented in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From nicola.lagloria at gmail.com Wed Apr 20 10:46:31 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:46:31 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: http://v-lad.org/projects/gnu.io.android/ We had, a little bit, modified the code to make it works in our devices, but the porting is well done. Nicola On Wed, Apr 20, 2011 at 4:04 PM, Andre-John Mas wrote: > > On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: > > > Hi Is RXTX is a replacement for javax.comm package or we need both these > in order to work with serial ports from java / android. > > RXTX is a separate implementation of the javax.comm API. The API presented > in gnu.io is meant to follow the API of javax.comm, > but uses a separate name space and uses a different implementation. > > What the impact is on Android I can not say, for lack of experience on this > platform. Maybe someone else can provide an answer? > > Andre > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.lagloria at gmail.com Wed Apr 20 10:52:00 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 18:52:00 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> References: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: You're wrong. It is not Android that has a serial port but rather a smartphone. Android, as you can read around the net, is used in many embedded systems for applications beyond the mobile world. In those applications you need serial ports (automation/control systems). Regards Nicola On Wed, Apr 20, 2011 at 6:37 PM, John G. Lussmyer wrote: > Well, since Android devices don't have serial ports, it doesn't seem > relevant. > > > On 4/20/2011 7:04 AM, Andre-John Mas wrote: > >> On 15-Apr-2011, at 04:35, Nevara, Jayaprakash wrote: >> >> Hi Is RXTX is a replacement for javax.comm package or we need both these >>> in order to work with serial ports from java / android. >>> >> RXTX is a separate implementation of the javax.comm API. The API presented >> in gnu.io is meant to follow the API of javax.comm, >> but uses a separate name space and uses a different implementation. >> >> What the impact is on Android I can not say, for lack of experience on >> this platform. Maybe someone else can provide an answer? >> >> Andre >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Apr 20 11:57:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 20 Apr 2011 20:57:34 +0300 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF0BCB.4060300@CasaDelGato.Com> Message-ID: On 4/20/11 19:37, "John G. Lussmyer" wrote: >Well, since Android devices don't have serial ports, it doesn't seem >relevant. At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go hardware and can thus act as a host so you can plugin a ubs-to-serial converter and that is where rxtx comes in. Also there are bluetooh based serial ports. br Kusti From Cougar at CasaDelGato.Com Wed Apr 20 12:17:48 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 11:17:48 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: Message-ID: <4DAF234C.9010305@CasaDelGato.Com> On 4/20/2011 10:57 AM, Kustaa Nyholm wrote: > > At least some Android devices (Samsung Galaxy IIRC) have usb-on-the-go > hardware and can thus act as a host so you can plugin a ubs-to-serial > converter and that is where rxtx comes in. Also there are bluetooh > based serial ports. Ok, I had never seen a device with a serial port yet. The Bluetooth serial devices you just use the built-in bluetooth support. I already have one app that reads data from serial via bluetooth. From nicola.lagloria at gmail.com Wed Apr 20 12:24:54 2011 From: nicola.lagloria at gmail.com (Nicola La Gloria) Date: Wed, 20 Apr 2011 20:24:54 +0200 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF234C.9010305@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: I would be happy to show you our Android devices (wall panel) for home automation, that use rs 485 serial port and Modbus communication ;) Best, Nicola On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer wrote: > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth support. > I already have one app that reads data from serial via bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Wed Apr 20 13:00:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 20 Apr 2011 12:00:24 -0700 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: References: <4DAF234C.9010305@CasaDelGato.Com> Message-ID: <4DAF2D48.9080809@CasaDelGato.Com> Hmm, I would love to find a 5-8" 12v powered Android panel I could use in a car. On 4/20/2011 11:24 AM, Nicola La Gloria wrote: > I would be happy to show you our Android devices (wall panel) for home > automation, that use rs 485 serial port and Modbus communication ;) > > Best, > > Nicola > > > On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer > > wrote: > > > Ok, I had never seen a device with a serial port yet. > The Bluetooth serial devices you just use the built-in bluetooth > support. I already have one app that reads data from serial via > bluetooth. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Wed Apr 20 14:04:44 2011 From: jredman at ergotech.com (Jim Redman) Date: Wed, 20 Apr 2011 14:04:44 -0600 Subject: [Rxtx] Is RXTX a replacement for Javax.comm package In-Reply-To: <4DAF2D48.9080809@CasaDelGato.Com> References: <4DAF234C.9010305@CasaDelGato.Com> <4DAF2D48.9080809@CasaDelGato.Com> Message-ID: <4DAF3C5C.8050309@ergotech.com> Slight off-topic. Car power is so dirty you'd do better with something that will run of USB (5V) and use a converter. I'd like nominal 24V (24VDC+/- about 15%) Android panel for industrial applications. For those not familiar with this environment,v 24VDC is the only voltage you can be pretty much certain will be in an industrial panel. They may well not have single-phase AC - it's common to have a box with 24VDC and some high voltage 2-phase, or even 3-phase power. On 04/20/2011 01:00 PM, John G. Lussmyer wrote: > Hmm, I would love to find a 5-8" 12v powered Android panel I could use > in a car. > > On 4/20/2011 11:24 AM, Nicola La Gloria wrote: >> I would be happy to show you our Android devices (wall panel) for home >> automation, that use rs 485 serial port and Modbus communication ;) >> >> Best, >> >> Nicola >> >> >> On Wed, Apr 20, 2011 at 8:17 PM, John G. Lussmyer >> > wrote: >> >> >> Ok, I had never seen a device with a serial port yet. >> The Bluetooth serial devices you just use the built-in bluetooth >> support. I already have one app that reads data from serial via >> bluetooth. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > -- > -- > John G. Lussmyer mailto:Cougar at CasaDelGato.Com > Electric Vehicle Battery Monitoring Systems,http://www.CasaDelGato.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 mike.ab3ap at gmail.com Mon Apr 25 13:39:24 2011 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Mon, 25 Apr 2011 15:39:24 -0400 Subject: [Rxtx] WebStart, rxtx, and amd64 Message-ID: <4DB5CDEC.2010707@gmail.com> I've run into an odd problem that hopefully someone else has seen and solved. If I use WebStart for 32-bit linux, Intel, all is well. Java Console shows me that it arrives at the web server as os.name=Linux and os.arch=i386 and, sure enough, the jnlp file (attached below) points it to the correct native jar. However, if I try the same with 64-bit linux, Java Console shows os.name=Linux and os.arch=amd64. The bad news is that the jnlp file does not supply -any- rxtx native lib via WebStart. The only way I can get it to work is by adding the last linux entry that does not specify the architecture. I assume I'm doing something wrong but haven't figured it out yet. Thanks for any ideas! Mike RXTX ajmas Java API for serial port communication Java API for serial port communication. From dietmar at dl2sba.de Tue Apr 26 00:52:55 2011 From: dietmar at dl2sba.de (Dietmar Krause) Date: Tue, 26 Apr 2011 08:52:55 +0200 Subject: [Rxtx] Bluetooth port not found on Windows 7 64bit Message-ID: <7C13C59DB1CC2D45934298DA5B10BF830641078127@winxbede24.exchange.xchg> Hi List I'm using this code to find available COM ports: Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { CommPortIdentifier portId = null; portId = portList.nextElement(); System.out.println("getPortList:: found port[" + portId.getName() + "]"); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { rc.add(portId.getName()); } } This gives me the following trace when enabling debug mode in CommPortIdentifier.java: CommPortIdentifier:static initialization() CommPortIdentifier:addPortName(COM4) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() Have not implemented native_psmisc_report_owner(PortName)); in CommPortIdentifier static CommPortIdentifier:getPortIdentifiers() CommPortIdentifier:addPortName(COM6) CommPortIdentifier:AddIdentifierToList() CommPortIdentifier:AddIdentifierToList() null CommPortIdentifier:getName() getPortList:: found port[COM6] << this is from java code CommPortIdentifier:getPortType() CommPortIdentifier:getName() COM6 is listed but is the incoming port of the device?! I need COM4 to communicate with it. But COM4 is not returned by getPortIdentifiers(). Any ideas whats going wrong? Kind regards Dietmar, DL2SBA -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueeagle2 at gmail.com Fri Apr 29 16:05:27 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Fri, 29 Apr 2011 15:05:27 -0700 Subject: [Rxtx] RXTX and Eclipse on Linux Message-ID: I installed the RXTX plugins for eclipse on my Ubuntu 10.04 machine, but while my Java code lists the serial ports, when I try to send data to my device which is connected by way of a virtual serial port /ttyACM0 nothing happens. I was trying to send data to the SparkFun UBW(Universal Bit Whacker) to blink an LED. I can do this in C#, but not in Java and the code is almost identical except for the serial port code so I am assuming it is the RXTX that is causing the problem. Besides the RXTX plugins for Eclipse I was wondering if there is anything else I need to install to get this to work? I have attached my code file in case anyone is able to help me. [?] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 97 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UBW_Console.java Type: text/x-java Size: 6684 bytes Desc: not available URL: From blueeagle2 at gmail.com Sat Apr 30 02:40:08 2011 From: blueeagle2 at gmail.com (blueeagle2 at gmail.com) Date: Sat, 30 Apr 2011 01:40:08 -0700 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux Message-ID: Okay, before I had the rxtx installed in eclipse as a plug-in, but though it detected the /dev/ttyACM0 port, it would not communicate with it. So, I decided to just install the Linux version of RXTX. In my case I had to use the CloudHopper version as I have a 64-bit version. Now, the code detects only my /ttyS0 port and not the /dev/ttyACM0 port. From what I have been reading, ports in RXTX are hard coded and I need to recompile the rxtx source code. Unfortunately, Cloudhopper does not supply source code so I will have to recompile the original 32-bit code into 64-bit code. Does anyone have a good tutorial on how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Sat Apr 30 03:21:19 2011 From: hybris0 at gmail.com (Hybris) Date: Sat, 30 Apr 2011 11:21:19 +0200 Subject: [Rxtx] RXTX does not support Virtual Com ports in Linux In-Reply-To: References: Message-ID: 2011/4/30 : > reading, ports in RXTX are hard coded and I need to recompile the rxtx > source code.? Unfortunately, Cloudhopper does not supply source code so I http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F From Wei.Shen at Honeywell.com Fri Apr 1 09:43:25 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Fri, 1 Apr 2011 11:43:25 -0400 Subject: [Rxtx] [rxtx] disconnect event (help) Message-ID: <83B3B1411349194D9D05821CEF48E78C0245C037@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Sat Apr 2 21:59:53 2011 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Sat, 2 Apr 2011 21:59:53 -0600 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: References: Message-ID: <000001cbf1b3$9a6e7000$cf4b5000$@Griffith@se-eng.com> Was this ever resolved? Bruce Griffith From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Selva Nayagam Sent: Wednesday, 30 March 2011 12:01 AM To: rxtx at qbang.org Subject: [Rxtx] Serial Communication in Winsow7 Dear All, I have written a serial programing using rxtx which works fine for windows XP. For Windows7 it does not works. I mean send happens properly but the receive is not happening properly. Data gets lost often. With Regards Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Sun Apr 3 05:58:08 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Sun, 3 Apr 2011 12:58:08 +0100 Subject: [Rxtx] Serial Communication in Winsow7 In-Reply-To: <4968854523619037199@unknownmsgid> References: <4968854523619037199@unknownmsgid> Message-ID: Works fine for me! I suspect programmer's error or, at a push, some USB/Serial adapter issue. From Kustaa.Nyholm at planmeca.com Thu Apr 7 23:47:20 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 08:47:20 +0300 Subject: [Rxtx] Thread safety Message-ID: Sorry to resurrect this half year old thread but I've got reason to revisit this subject: On Thu, 8/19/10 this is where we left off: >>> Is javacomm thread-safe by >>> specification? >> >> The javax.comm API doesn't mention thread safety. The >> sample code on Sun's site shows port monitoring threads >> being created - so it can be assumed the API was expected to >> be used in a multi-threaded application. The >> java.io.InputStream and java.io.OutputStream APIs make it >> clear that those classes are not thread-safe. > Oops, I should have checked the JavaDocs before clicking Send. > The java.io.InputStream and java.io.OutputStream abstract classes > are thread-> safe, but > their subclasses might not be. This is going to a bit academic whit no bases in actual code. Hmm, if a class is declared (in the javadoc) to be thread safe, is it ok for the derived class to break this contract? After all it is very likely that it is just the base class type/reference that gets passed around and thus the client have every right to expect that the contract is honored. Looking myself at the InputStream javadoc I found only two instances of word thread and then in connection with available() saying: "The next caller might be the same thread or another thread." OutputStream javadoc does not mention threads. Not very specific, huh? But if we take it that the Javacomm classes are thread safe, what thread safety means here? What does it mean that an InputStream is thread safe? Is there any meaningful/reasonable expectancy if read()s are called concurrently? With what result, what would be a reasonable expectation / outcome? I don't think so, except of course that they should not mess up the internal state of the stream or system to a point that will harm other operations. Calling close() from one thread when another thread is read()ing seems to be reasonable and should result in the stream closing and the read() to terminate yearly, perhaps with an exception? This seems to be just me thinking aloud but thoughts are welcome! I guess my main point is that implementing thread safety often incurs cost at runtime because of the need to synchronize() {} stuff and this is best avoided in any library if there is no meaningful use scenario. And users of the library can always mutex their access to the library if they need where as if the library is unnecessary mutexed they can't take the overhead away even if they don't need it. Going on, thinking out loud. It should be perfectly ok to use one thread to operate the OutputStream and another the InputStream. Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() need to be thread safe so that when multiple threads need open different ports they can, or if they try to open the say port they get a graceful denial with PortInUse exception. Setting the SerialPort attributes (baud etc) and port signals from multiple threads does not make much sense, but should at very least leave the port in consistent state and besides internal implementation issues dictate that port signal state changes are not fast anyway so providing thread safety at some cost is not a big deal. There is no use scenario that makes sense to me where rapid changes of the baudrate etc make sense so mutexing is not a big issue there either. Like InputStream.read(), OutputStream.write() makes no sense to me to call this from multiple streams unless you have some mutex in place in the calling code, but on the otherhand calling close() while read()/write() is in progress and available() from multiple threads makes perfect sense to me. OutputStream.flush() is a borderline case, but I guess it should at very least drain the output even it the semantics are a bit unclear if a write is in progress. OutputStream.skip() and cheers Kusti From msemtd at googlemail.com Fri Apr 8 03:04:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 8 Apr 2011 10:04:15 +0100 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: I use rxtx in massively multi-threaded applications with things to note. I always handle reads from the event handler thread. My write operations are from various threads but from a synchronized method. I never allow the event handler thread to close the port. On 8 Apr 2011 06:53, "Kustaa Nyholm" wrote: > Sorry to resurrect this half year old thread but I've got reason to revisit > this subject: > > > On Thu, 8/19/10 this is where we left off: > > >>>> Is javacomm thread-safe by >>>> specification? >>> >>> The javax.comm API doesn't mention thread safety. The >>> sample code on Sun's site shows port monitoring threads >>> being created - so it can be assumed the API was expected to >>> be used in a multi-threaded application. The >>> java.io.InputStream and java.io.OutputStream APIs make it >>> clear that those classes are not thread-safe. >> Oops, I should have checked the JavaDocs before clicking Send. >> The java.io.InputStream and java.io.OutputStream abstract classes >> are thread-> safe, but >> their subclasses might not be. > > > > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? After all > it is very likely that it is just the base class type/reference > that gets passed around and thus the client have every right to > expect that the contract is honored. > > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." > > OutputStream javadoc does not mention threads. > > Not very specific, huh? > > But if we take it that the Javacomm classes are thread safe, > what thread safety means here? > > What does it mean that an InputStream is thread safe? > > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? > > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. > > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? > > > This seems to be just me thinking aloud but thoughts are welcome! > > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. > > > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the OutputStream > and another the InputStream. > > > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. > > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, but should at > very least leave the port in consistent state and besides > internal implementation issues dictate that port signal state > changes are not fast anyway so providing thread safety at some > cost is not a big deal. There is no use scenario that makes > sense to me where rapid changes of the baudrate etc make sense > so mutexing is not a big issue there either. > > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, but on the otherhand calling close() > while read()/write() is in progress and available() > from multiple threads makes perfect sense to me. OutputStream.flush() > is a borderline case, but I guess it should at very least drain > the output even it the semantics are a bit unclear if a write is > in progress. OutputStream.skip() and > > cheers Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Apr 8 04:01:15 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 8 Apr 2011 13:01:15 +0300 Subject: [Rxtx] Thread safety In-Reply-To: Message-ID: On 4/8/11 12:04, "Michael Erskine" wrote: >I use rxtx in massively multi-threaded applications with things to note. >I always handle reads from the event handler thread. My write operations >are from various threads but from a synchronized method. I never allow >the event handler thread to close the port. Thanks Michael for taking interest. Your view seems to coincide with my view of thread safety in this context. br Kusti From tjarvi at qbang.org Fri Apr 8 08:25:02 2011 From: tjarvi at qbang.org (tjarvi at qbang.org) Date: Fri, 8 Apr 2011 14:25:02 +0000 Subject: [Rxtx] My Photoset Nr.6856 Message-ID: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Hi There. I am a very fun gal who loves to take pictures as well as recieve them... You can find me in the middle of this page: I am giving out my personal info here: http://girlsdate.ru Name: Linda F., New York I am a: Woman Age: 27 y/o Height: 5-6 Weight: 118 Lbs Hair: Brown currently www.girlsdate.ru From thompd at gmail.com Fri Apr 8 08:44:06 2011 From: thompd at gmail.com (Dave Thompson) Date: Fri, 8 Apr 2011 10:44:06 -0400 Subject: [Rxtx] My Photoset Nr.6856 In-Reply-To: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> References: <2285210629.DZKTEP6W918053@slawwgqdzpzzz.ujttrpkghchht.com> Message-ID: But can she can help with rxtx debugging? Oye. On Fri, Apr 8, 2011 at 10:25, wrote: > Hi There. I am a very fun gal who loves to take pictures as well as recieve > them... You can find me in the middle of this page: > > I am giving out my personal info here: > http://girlsdate.ru > > Name: Linda F., New York > I am a: Woman > Age: 27 y/o > Height: 5-6 > Weight: 118 Lbs > Hair: Brown currently > > www.girlsdate.ru > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at diekrieger.at Fri Apr 8 13:23:18 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 21:23:18 +0200 Subject: [Rxtx] icpcon 7561 rs485 Message-ID: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi at all! First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. So, what's my requestt: I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. I need the RS485 interface and I want to use RXTX for this purpose. RXTX is installed and works (thanks rxtx-wiki!). I can detect the serial ports (COM1,...COM23). But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. If I use the PORT_SERIAL I can use the RS232 port of the converter. Is there a trick to send the data to the RS485 port? Any hint? Thank you in advance and best regards, Tobias Krieger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn2CmAAoJEGl5je/gDQKOCyYH/079JpNppm5DBkmliNGqo0ot U7rV4QUaX7JyxMWUhqfgyG12os7r86ND/53XTeImIek0gRGWjTi0iJzJv3czqQcq qP3iCE5HVrRUXIEVnxd4L4zyJNMyPvAdV9mHIbCvX6sVeE9cU2PMyniJ4OKDdEwM J7yo4WKMNjwB42v67HEyuV+HresXLAwv7Tq/24RkgSZLCCh3OlB5JMOfaUQIXoOp v+nx7qip9KgQIjNahiZ+THnmKn4vojUd7hpooWmA2aF58pR0CUAEILlzHbytGNlM 7Jrs3tY+vN0KCOCAmRT1d/TgjJ4eIphz+/hP4pOmEgEwKEuYK8t02D0E+JBH0R8= =sRa/ -----END PGP SIGNATURE----- From tjarvi at qbang.org Fri Apr 8 13:27:48 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Apr 2011 13:27:48 -0600 (MDT) Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: On Fri, 8 Apr 2011, Tobias Krieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi at all! > > First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. > > So, what's my requestt: > > I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. > > I need the RS485 interface and I want to use RXTX for this purpose. > > RXTX is installed and works (thanks rxtx-wiki!). > > I can detect the serial ports (COM1,...COM23). > > But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. > > If I use the PORT_SERIAL I can use the RS232 port of the converter. > > Is there a trick to send the data to the RS485 port? Any hint? > > Thank you in advance and best regards, > Hi Tobias The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. From tobias at diekrieger.at Fri Apr 8 15:05:28 2011 From: tobias at diekrieger.at (Tobias Krieger) Date: Fri, 8 Apr 2011 23:05:28 +0200 Subject: [Rxtx] icpcon 7561 rs485 In-Reply-To: References: <0F7FEBB7-1217-464D-8EA5-0FDDB5795641@diekrieger.at> Message-ID: <48F1AAC3-7F5E-4B62-B0BC-EA8145B76060@diekrieger.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh! I understand. I actually just simply send with RXTX the serial commands and the dongle converts to RS485. So I guess the dongle detects if a RS485 component is connected and then switches to the RS485 port, else the dongle uses RS232 output port. Anything I should be aware of? Thanks Trent! - -Tobias Am 08.04.2011 um 21:27 schrieb Trent Jarvi: > > > On Fri, 8 Apr 2011, Tobias Krieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi at all! >> >> First, thanks for this mailing list. I'm new to RXTX and fairly new to JAVA. >> >> So, what's my requestt: >> >> I'm using a ICPCON 7561 USB to RS232/485/422 converter on a Windows XP machine. The converter gets detected in the device manager (ICP75XX usb to serial converter COM2...as example), the drivers are installed. >> >> I need the RS485 interface and I want to use RXTX for this purpose. >> >> RXTX is installed and works (thanks rxtx-wiki!). >> >> I can detect the serial ports (COM1,...COM23). >> >> But RXTX does not detect the RS485 Port (...CommPortIdentifier.PORT_RS485...) of the converter. >> >> If I use the PORT_SERIAL I can use the RS232 port of the converter. >> >> Is there a trick to send the data to the RS485 port? Any hint? >> >> Thank you in advance and best regards, >> > > Hi Tobias > > The RS485 support in rxtx is a shell lacking implementation. You should be able to use the Serial version with your dongle. > > The original thought behind the RS485 class is that it is nearly possible to switch states fast enough in a kernel driver to perform RS485 communication with a simple UART. > > In reality, this is an error prone solution and the dong'e you have is the right path with RXTX Serial support. The hardware does the switching for you. I've seen NI and noname RS232<->RS485 dongles work with RXTX in the past. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJNn3iYAAoJEGl5je/gDQKOKvYIAJbnnO0cN8tqvf/hLoPeRyIg TvIfuFP6FP+jsx/n1v86MS//5gNvxxexZAUrdCFI5/N3yvgeHlnDaYWKKMvTw6H2 ZV4rll1VU0+kzGpBLKCUhl2ugFFTDks1MD/XbIN1iGh7Ei+kxrVTzWwiIMqm8I4X 1Uk++aLO93JUFkEV1rZK+89FRsGfJFbVF+5bYQOaswc8KlSSfHOhYoamREbyiTFS +ZKJiDdOQXshrrzFvcw7STaGkj8QK+hplAlII9B8JvWXP8Zeb6D/w+czT7WD5IoG U4nS/gy1fI7f9sBLMmq3toAesX+GnIE4jE4sT1+KDoAM3N/OwPSMGUvt9Js2xCw= =p575 -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Mon Apr 11 04:44:09 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Apr 2011 12:44:09 +0200 Subject: [Rxtx] Thread safety In-Reply-To: References: Message-ID: <20110411104409.GB6764@elberon.bln.de.ingenico.com> * Kustaa Nyholm wrote on Fri, Apr 08, 2011 at 07:47 +0200: > Sorry to resurrect this half year old thread but I've got > reason to revisit this subject: > > On Thu, 8/19/10 this is where we left off: > > >>> Is javacomm thread-safe by > >>> specification? > >> > >> The javax.comm API doesn't mention thread safety. The > >> sample code on Sun's site shows port monitoring threads > >> being created - so it can be assumed the API was expected to > >> be used in a multi-threaded application. The > >> java.io.InputStream and java.io.OutputStream APIs make it > >> clear that those classes are not thread-safe. > > Oops, I should have checked the JavaDocs before clicking Send. > > The java.io.InputStream and java.io.OutputStream abstract classes > > are thread-> safe, but their subclasses might not be. > > This is going to a bit academic whit no bases in actual code. > > Hmm, if a class is declared (in the javadoc) to be thread safe, > is it ok for the derived class to break this contract? In Java it is, but logically I think it makes not much sense. Actually, an interface specifying that you either have to implement a specific property OR NOT in the end tells nothing. Same thing for those `optional methods'. Logically, using an interface is to guarantee that a specific property/method exists. Recommending not to implement them in some cases and make them throwing some NotImplementedExceptions is just hiding that obviously the abstraction is wrong. When all FourTireCars have four tires, then there must be not specialisation of a FourTireCar with only three tires and getFourthTire shall not throw TireNotAvailableException :-) See InputStream.reset(). But even saying "thread safe" IMHO makes no sense. What should it mean? Can it be invoked without crashing? Yes, it can be used. It might have unexpected effects, but maybe just because of a wrong expection? Or does it mean it can safely be used without unexpected side effects in whichever way without and assumptions on where the excution thread(s) are? This is impractical I think, usually at least free re-entrance is very hard to realize. So the question is what is allowed to be done from different threads. For example, most Java code should be thread-safe if leaf object instance calls are serialized, such as via one and the same synchronized only. If I understood right, this is what Michael is doing, but he is using an event based approached with usually is more asynchronous with few threads (dedicated to small tasks, event sources or sinks). > After all it is very likely that it is just the base class > type/reference that gets passed around and thus the client have > every right to expect that the contract is honored. I don't think this is what the Java doc intends to say. I think what it means is that you cannot expect that, because the InputStream interface (which IMHO is very weak anyway due to its design Bugs like void available(void) etc) does not guarantee that. It tells, more or less, "by accident, the base class, which does almost nothing, is thread safe, whatever this means, but sub classes may do something completely different, throw NotImplemented, ConcurrentAccessException or even deliver duplicated phantom data to multiple threads. > Looking myself at the InputStream javadoc I found only two instances > of word thread and then in connection with available() saying: > "The next caller might be the same thread or another thread." Which tells nothing, because an Interface in Java has no way to prohibit to be called from another thread, because there is not thread-local visibility in Java (i.e. you cannot enforce at compile time that an object can be used by a particular thread only). Since IOException is also used by reset() when this concept-rape is not implemented, maybe some subclass throws IOException when available is called by a thread different from the one who called the last write or so. Interesting is ByteArrayInputStream, which works on a foreign byte[] (not copied) and thus can make no guarantee about reset() behavior (another thread can modify byte[] between mark() and reset() and surely read will return different data I think. An implementation could even internally serialize all calls. It would be thread-safe, of course, but as soon as one thread invokeds a blocking read, all other threads have to wait. Would be valid according to the interface, but almost unusable. > Is there any meaningful/reasonable expectancy if read()s are > called concurrently? The reasonable expectation IMHO is that one and only one of the read invoking threads get a particular piece of data (i.e. each received byte is delivered to exactly one caller), if having a happens-before relationship the caller threads could even interpret the bytes in the correct order :-) > With what result, what would be a reasonable expectation / outcome? > > I don't think so, except of course that they should not mess up > the internal state of the stream or system to a point that > will harm other operations. Even if internally it's safe, in case of serial I/O the returned data would be difficult to handle (unless the protocol has single byte command/responses) I think. > Calling close() from one thread when another thread is read()ing > seems to be reasonable and should result in the stream closing and > the read() to terminate yearly, perhaps with an exception? Yes, or I think better close waiting for the read to finish, would be safer regarding to the contract of the API, but in practice with the disadvantage that a intended brute-force-close would not abort the read, which can make sense when for example the user closes the application. > This seems to be just me thinking aloud but thoughts are welcome! I think, if this really matters, the calling code cannot rely on such assumptions. However, to be able to implement a reasonable systems, some assumptions have to be made. For example I would assume that when having multiple InputStream objects for different resources (COM ports or so), it works safely at least if each instance is used by one and the same thread all the time, even if multiple instances are used by multiple instances. But this, a 1:1 thread:stream approach can be implemented, which might be suited for simple applications (because the code should be simple). Another assumption that you can have one event handler / message pump thread but do the I/O in a different thread. This IMHO makes much sense to be able to decouple potentially time consuming operations (even non-blocking I/O could take several hunderds milliseconds). What do you think? > I guess my main point is that implementing thread safety often incurs > cost at runtime because of the need to synchronize() {} stuff and > this is best avoided in any library if there is no meaningful use > scenario. Yes, and additionally lead to liveness problems (dead locks). What often seems to be forgotten but strictly speaking shall be considered is what happens if derived classes call themselfs in some way. synchronized does not help here: because the calling thread is the same, the second call is performed (otherwise, it would be an unconditional dead lock, also not helpful)! (An example could be a serial logger using some OutputStream to write log messages such as error messages and having an error on this logging, leading to an error message, invoking the serial log publisher again) > And users of the library can always mutex their access > to the library if they need where as if the library is unnecessary > mutexed they can't take the overhead away even if they don't need it. But sometimes this could become very uncomfortable I think. Logging, for example, IMHO should always be "as thread-safe, re-entrant and non-blocking as possible", because using logging should be simple and quick. In case of Serial I/O I think all resources that are shared between the serial instances and used by them should be protected, because an application using it should not need to know how to lock that access (to something that might not even be visible to the applicaiton, such as a global list of open connections or COM ports or so). > Going on, thinking out loud. > > It should be perfectly ok to use one thread to operate the > OutputStream and another the InputStream. You mean this as requirement? I think there is definitely no such guarantee. Even here, because both, I think, are just wrappers for something that communicates and they share the comm resource (file handle). Is it needed to allow read and write on the same link at the same time from different processes? Could be argued, because it supports full duplex, but I think this needs internal mutexes. > Calling PortIdentifier.opengetPortIdentifiers() PortIdentifier.open() > need to be thread safe so that when multiple threads need open > different ports they can, or if they try to open the say port > they get a graceful denial with PortInUse exception. You assume, you can open a port only once? Why isn't it allowed to open COM1 twice and use one only for reading and the other only for writing? (I also think at the moment this is not possible, but at least this should be documented if it is a limitation of the library, not of the OS). > Setting the SerialPort attributes (baud etc) and port signals > from multiple threads does not make much sense, I think signals do; having a DCD observing thread for example. Especially if writing big blocks of data it might be important. API / impl should define what happens when signals change. I think, here nothing happens, but this might be unexpected. If you have a modem and you send data, as soon as DCD gets low the write should stop with some CARRIER LOST - but how to implement best and generic? Is this even possible with InputStream? I think an idea could be to define that read(bytes[]) returns on every signal change to allow a caller to query signal state. Since OS queues are used, at least, this won't be very precise anyway, but probably sufficient for practice. Of course this would be simple to do if polling would be an option, but this wastes CPU. > Like InputStream.read(), OutputStream.write() makes no sense to > me to call this from multiple streams unless you have some mutex > in place in the calling code, No sense? Isn't this is typical full duplex usage? oki, Steffen From Kustaa.Nyholm at planmeca.com Mon Apr 11 22:48:42 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 12 Apr 2011 07:48:42 +0300 Subject: [Rxtx] Thread safety In-Reply-To: <20110411104409.GB6764@elberon.bln.de.ingenico.com> Message-ID: On 4/11/11 13:44, "Steffen DETTMER" wrote: Thanks Steffen fo taking interest. >> >> Hmm, if a class is declared (in the javadoc) to be thread safe, >> is it ok for the derived class to break this contract? > >In Java it is, but logically I think it makes not much sense. > >Actually, an interface specifying that you either have to >implement a specific property OR NOT in the end tells nothing. >Same thing for those `optional methods'. Logically, using an >interface is to guarantee that a specific property/method exists. >Recommending not to implement them in some cases and make them >throwing some NotImplementedExceptions is just hiding that >obviously the abstraction is wrong. Yeah, you are right but in this case (InputStream etc) it is what it is I need to deal with it. > >When all FourTireCars have four tires, then there must be not >specialisation of a FourTireCar with only three tires and >getFourthTire shall not throw TireNotAvailableException :-) >See InputStream.reset(). Nice parallel! However, behind all stupid (API) decision you often find a 'good' and pragmatic reason. Like timeouts on InputStream return without data which is against the spec per se. > >But even saying "thread safe" IMHO makes no sense. What should it >mean? Can it be invoked without crashing? Yes, it can be used. It >might have unexpected effects, but maybe just because of a wrong >expection? Or does it mean it can safely be used without >unexpected side effects in whichever way without and assumptions >on where the excution thread(s) are? This is impractical I think, >usually at least free re-entrance is very hard to realize. Indeed, just the kind of problems that came to my mind, hence resurrecting this thread (no pun intended!). > >So the question is what is allowed to be done from different >threads. For example, most Java code should be thread-safe if >leaf object instance calls are serialized, such as via one and >the same synchronized only. Yes, at the cost of synchronization, which in this context (serial port) may no be an issue. >I don't think this is what the Java doc intends to say. I think >what it means is that you cannot expect that, because the >InputStream interface (which IMHO is very weak anyway due to its >design Bugs like void available(void) etc) does not guarantee >that. It tells, more or less, "by accident, the base class, which >does almost nothing, is thread safe, whatever this means, but sub >classes may do something completely different, throw >NotImplemented, ConcurrentAccessException or even deliver >duplicated phantom data to multiple threads. Yes, you could (probably should!) read it like that but it depends on the reader. A casual reader might take it at face value and rely on th ThisInputStream IS-A InputStream therefore everything it says the InputStream javadoc applies. >Interesting is ByteArrayInputStream, which works on a foreign >byte[] (not copied) and thus can make no guarantee about reset() >behavior (another thread can modify byte[] between mark() and >reset() and surely read will return different data I think. And other example of the API issues! However you this too falls under the question what thread-safety means in this context. > >The reasonable expectation IMHO is that one and only one of the >read invoking threads get a particular piece of data (i.e. each >received byte is delivered to exactly one caller), if having a >happens-before relationship the caller threads could even interpret >the bytes in the correct order :-) Yes, that is a reasonable in expectation in my view. > >Even if internally it's safe, in case of serial I/O the returned >data would be difficult to handle (unless the protocol has single >byte command/responses) I think. Agree, my reasoning is that it is not very reasonable to expect (and support) multiple threads to read from the same input stream without an external mutex, and hence, in a way, this in contradiction with my/your statement in the above paragraph: if the expectation is that you need an external synchronization anyway, why bother with it inside the InputStream....!? >Yes, or I think better close waiting for the read to finish, >would be safer regarding to the contract of the API, but in >practice with the disadvantage that a intended brute-force-close >would not abort the read, which can make sense when for example >the user closes the application. >From the implementation point of view I get constant crashes in Windows if I do not let an async call I/O return from the WaitMultipleObjects call. Which is a bit of a nuisance since I do think many people expect close() to block even briefly. But then again there is not promise about that in the javadoc > >> This seems to be just me thinking aloud but thoughts are welcome! > >I think, if this really matters, the calling code cannot rely on >such assumptions. However, to be able to implement a reasonable >systems, some assumptions have to be made. For example I would >assume that when having multiple InputStream objects for >different resources (COM ports or so), it works safely at least >if each instance is used by one and the same thread all the time, >even if multiple instances are used by multiple instances. Agree. > >Another assumption that you can have one event handler / message >pump thread but do the I/O in a different thread. This IMHO makes >much sense to be able to decouple potentially time consuming >operations (even non-blocking I/O could take several hunderds >milliseconds). > >What do you think? Agree. > >> And users of the library can always mutex their access >> to the library if they need where as if the library is unnecessary >> mutexed they can't take the overhead away even if they don't need it. > >But sometimes this could become very uncomfortable I think. >Logging, for example, IMHO should always be "as thread-safe, >re-entrant and non-blocking as possible", because using >logging should be simple and quick. Yes, agree about logging. > >In case of Serial I/O I think all resources that are shared >between the serial instances and used by them should be >protected, because an application using it should not need to >know how to lock that access (to something that might not even be >visible to the applicaiton, such as a global list of open >connections or COM ports or so). Agree. > >> Going on, thinking out loud. >> >> It should be perfectly ok to use one thread to operate the >> OutputStream and another the InputStream. > >You mean this as requirement? >I think there is definitely no such guarantee. >Even here, because both, I think, are just wrappers for something >that communicates and they share the comm resource (file handle). What I ment was that the user of [RXTX] is perfectly reasonable if he thinks that he can call write from one thread while an other thread is performing a read and this should be supported. > >Is it needed to allow read and write on the same link at >the same time from different processes? Could be argued, because >it supports full duplex, but I think this needs internal mutexes. Ah that is what you said. > You assume, you can open a port only once? >Why isn't it allowed to open COM1 twice and use one only for >reading and the other only for writing? Well, I'm actually going to leave this 'implementation defined'. I don't know if in Windows you can open the same port twice even if other is read and another is write (maybe I should check) but in *nix it seems there is no mechanism to guarantee mutual exclusion if an other application is playing ball, so I won't bother. May change my mind about that though. >(I also think at the moment this is not possible, but at least >this should be documented if it is a limitation of the library, >not of the OS). > >> Setting the SerialPort attributes (baud etc) and port signals >> from multiple threads does not make much sense, > >I think signals do; having a DCD observing thread for example. >Especially if writing big blocks of data it might be important. >API / impl should define what happens when signals change. Sorry I was not clear, I meant setting the same signal from two threads without some external sync in the application, however, this is a non issue in the implementation I think. >I think, here nothing happens, but this might be unexpected. If >you have a modem and you send data, as soon as DCD gets low the >write should stop with some CARRIER LOST - but how to implement >best and generic? Is this even possible with InputStream? I'm not sure I follow you here. > >I think an idea could be to define that read(bytes[]) returns on >every signal change to allow a caller to query signal state. Ok, got it know. Hmmm, sort of makes sense, but I don't see how to implement that reliably and reasonably in this frame (JavaComm) framework. >Since OS queues are used, at least, this won't be very precise >anyway, but probably sufficient for practice. > >Of course this would be simple to do if polling would be an >option, but this wastes CPU. Exactly. > >> Like InputStream.read(), OutputStream.write() makes no sense to >> me to call this from multiple streams unless you have some mutex >> in place in the calling code, > >No sense? Isn't this is typical full duplex usage? Sorry, was not clear here, what I meant that it is not reasonable to do read from multiple threads (without some external mutex) but it of course reasonable for one thread to read and other write. br Kusti From andy at zrmt.com Tue Apr 12 03:28:23 2011 From: andy at zrmt.com (Andy Loughran) Date: Tue, 12 Apr 2011 10:28:23 +0100 Subject: [Rxtx] rxtx on Windows 7 (replacing javax.comm) Message-ID: Guys, I've installed rxtx on